From owner-freebsd-ports Tue Mar 11 8:34:49 2003 Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6D6937B404; Tue, 11 Mar 2003 08:34:45 -0800 (PST) Received: from hun.org (hun.org [216.190.27.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4218943F93; Tue, 11 Mar 2003 08:34:44 -0800 (PST) (envelope-from attila@hun.org) Received: by hun.org (Postfix, from userid 1001) id 904FD5747C; Tue, 11 Mar 2003 16:34:43 +0000 (GMT) Date: Tue, 11 Mar 2003 16:34:43 +0000 (GMT) Message-Id: <20030311163443.tkzv40212@hun.org> From: Daniel Flickinger X-Mailer: AttilaMail with XEmacs & Postfix on FreeBSD 5.0-CURRENT X-Ballistic: N 37.218497 W 113.614979 X-Address: 31 N 700 E, St George UT 84770-3028 X-Squawk: (435) 680-0750 X-No-Archive: yes X-Tags: Sanity is the Playground for the Unimaginative Message-ID: <20030311065801.m31L33370@hun.org> In-Reply-To: <5257.1047339488@critter.freebsd.dk> References: Date: Tue, 11 Mar 2003 06:58:01 +0000 (GMT) To: phk@hun.org Cc: freebsd-current@FreeBSD.ORG, freebsd-ports@FreeBSD.ORG Subject: Re: bash2 or devfs problem? Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="text" Content-Transfer-Encoding: 8bit Content-Disposition: inline Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Sent: Tue, 11 Mar 2003 00:38:08 +0100 by Poul-Henning Kamp: | | In message , 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 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 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-ports" in the body of the message