Lately Larry Rosenman told:

> --On Tuesday, March 11, 2003 00:38:08 +0100 Poul-Henning Kamp 
> <[EMAIL PROTECTED]> wrote:
> > In message <[EMAIL PROTECTED]>, Conrad Sabatier
> > writes:
> >> Apparently, the nodes for the named pipes are not being created as they
> >> should.
> >>
> >> Is this a bash problem, or something in devfs not working as expected?
> > That's a good question...
> >
> > Has anybody found out what the standards conformant thing is for /dev/fd ?
> >
> > presently we do only 0,1 & 2, with the std{in,out,err} symlinks.
> >
> > If we are required to do all filedescriptors, we should do so with
> > fdescfs by default.
> It is supposed to (based on MY reading of the fd(4) man page on a UnixWare 
> (SysVr5) system)
> be ALL filedescriptors.
> 
> this paragraph seems to be the cogent part:
> 
> These files, conventionally called /dev/fd/0, /dev/fd/1, /dev/fd/2,
>    and so on, refer to files accessible through file descriptors. If file
>    descriptor n is open, these two system calls have the same effect:
>    fd = open("/dev/fd/n",mode);
>    fd = dup(n);

i read that only concerning *open* fds. (you can't dup a closed
[non-existant] fd).

furthermore i think there was a patch floating around addressing exactly
this issue. perhaps it was even committed (i'm too lazy to search for
it). solution was to test in configure for additional fds accessible
from /dev/fd/* and build without that feature if not.

cheers
  simon

-- 
/"\   http://corecode.ath.cx/#donate
\ /
 \     ASCII Ribbon Campaign
/ \  Against HTML Mail and News

Attachment: pgp00000.pgp
Description: PGP signature

Reply via email to