Mail Archives: djgpp-workers/1999/02/21/06:22:20
On Thu, 18 Feb 1999, Alain Magloire wrote:
> > There's no `chroot' in DJGPP's library. So, to support this
> > functionality, I'd suggest to override the library version of `chdir'
> > with a custom one that maintains the current root, prepends it to all
> > absolute file names, and disallows changing directory above the
> > current root. `chroot' will then just set an internal variable.
>
> Good idea, but not enough, chdir is not the only point of entry
> for the filesystem, for example in ftp someone could do a
> get D:/djgpp/etc/file
Right. So a library module called `putpath.c' will need to be
replaced with a custom one as well, and that custom version will need
to know about the current root. `putpath.c' is the single place used
by all other library functions to pass file names to the OS (that is
how devices like /dev/null are transparently supported by DJGPP).
> pid_t spawn (const char *path,
> const int fdlen,
> const int fdarray[],
> const char *argv,
> const char **envp);
>
> Node the fd*, so I can set the stdout/stdin for the child.
> fdarray[STDIN_FILENO] = socket_fd;
> fdarray[STDOUT_FILENO] = dup (socket_fd);
> fdarray[STDERR_FILENO] = dup (socket_fd);
> fdlen = 3;
If you means a simple spawn, then this inheritance of the three
standard file handles is already done automatically for you.
I mentioned this issue because running a child program asynchronously
in another DOS box doesn't make it a child program (as far as Windows
is concerned), and thus the file handles aren't inherited.
> Now I'm beginning to understand why WIN/DOS users reboot
> there machines so often.
I don't reboot mine at all ;-).
- Raw text -