Date: Tue, 11 Mar 2003 06:58:01 +0000 (GMT) From: Daniel Flickinger <attila@hun.org> To: phk@hun.org Cc: freebsd-current@FreeBSD.ORG, freebsd-ports@FreeBSD.ORG Subject: Re: bash2 or devfs problem? Message-ID: <20030311065801.m31L33370@hun.org> In-Reply-To: <5257.1047339488@critter.freebsd.dk> References: <XFMail.20030310155011.conrads@cox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Sent: Tue, 11 Mar 2003 00:38:08 +0100 by Poul-Henning Kamp:
|
| In message <XFMail.20030310155011.conrads@cox.net>, Conrad Sabatier writes:
|
| > I've noticed that bash's process substitution
| > fails under -CURRENT.
| >
| > For (an admittedly stupid, trivial) example:
| >
| > diff <(cat file1) <(cat file2)
| >
| > errors out with:
| >
| > diff: /dev/fd/63: No such file or directory
| > diff: /dev/fd/62: No such file or directory
| >
| > 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.
Somewhere around here I have a set of internal Western
Electric Bell Labs manuals from the early 80s but I can
not put my finger on them; if my memory is correct, I
think the following should have left the fifo read (#557)
open after the write command (#558), which it did not.
However, I have never used the fifo without a daemon
reader.
p3:tmp 556-> mkfifo fifo
p3:tmp 557-> < fifo cat &
[4] 31827
p3:tmp 558-> echo "junk" > fifo
p3:tmp 559-> junk
[4]+ Done cat <fifo
p3:tmp 559->
The following simple code indicates (at least to me) there
is not a problem with the file descriptors.
/*
read from named pipe
3311.0600 attila
*/
#include <stdio.h>
int main(int argc, char **argv)
{
char buffer[1024];
FILE *listen;
if ( argv[1] == NULL )
(void) fprintf(stderr, "fifo name required\n");
listen = fopen("fifo", "r+");
while (1)
if ( fgets(buffer, 1024, listen) != NULL )
fputs(buffer, stdout);
}
As long as this program is running --presumably in the
background-- you can echo lines to the fifo as above, one
after the other with no time out or limit, and from
different users, as long as they have write permission to
the fifo. The requirement is that the fifo must be open
for read/write (r+ mode, non-exclusive) before you can
write with another program (or the same for that matter).
An empty line does not close the read daemon.
In the above program I am not taking into account separate
streams as in print spoolers or that a daemon could be
used to hold a fifo open for a distinct transient program
to read a line.
If you put a sleep after each write, the fifo will
stack multiple lines and read them out slowly.
If the background read closes, you get an error:
p3:tmp 579-> echo "junk" >fifo
bash: fifo: Resource temporarily unavailable
p3:tmp 580->
This begs the question as to whether or not preloading a
fifo is in the spec... I don't think it was.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030311065801.m31L33370>