misc/77493: freebsd 5.3 + bash process substitution

[Travis Morgan]

The following reply was made to PR misc/77493; it has been noted by GNATS.

From: Travis Morgan <travis at bigfiber.net>
To: freebsd-gnats-submit at FreeBSD.org
Cc:  
Subject: Re: misc/77493: freebsd 5.3 + bash process substitution
Date: Wed, 23 Mar 2005 12:29:19 -0700

 I filed this bug with the bash bugs team as well and received the following response from them. According to Chet this would appear to be a FreeBSD problem, not a bash problem.
 
 Travis
 http://bigfiber.net
 
 Date: Wed, 9 Mar 2005 21:45:17 -0500
 From: Chet Ramey <chet at caleb.ins.cwru.edu>
 To: travis at bigfiber.net
 Subject: Re: process substitution data corruption on FreeBSD 5.3
 Cc: bug-bash at gnu.org, chet at po.cwru.edu
 Reply-To: chet.ramey at case.edu
 In-Reply-To: Message from travis at bigfiber.net of Sat, 05 Mar 2005 20:32:19 +0000 (id <20050305203219.69980.qmail at home.ecn.ab.ca>)
 Read-Receipt-To: chet.ramey at case.edu
 
 > Machine Type: i386-portbld-freebsd5.3
 > 
 > Bash Version: 3.0
 > Patch Level: 16
 > Release Status: release
 > 
 > Description:
 > 	Process substitution doesn't work on FreeBSD 5.3 due to corruption of the data. I've tested on other versions of FreeBSD (4.x) and Linux and there are no problems. On all of the 5.3 boxes I have tried though with Bash 3.x and Bash 2.x it does not work properly.
 > 	I don't know if this is a bash bug or a FreeBSD bug. I submitted a bug report to FreeBSD some time ago but haven't seen any activity on it.
 > 	http://www.freebsd.org/cgi/query-pr.cgi?pr=77493
 
 I think this is a FreeBSD bug.  I did some testing today using
 5.4-PRERELEASE. 
 
 The bash `read' builtin, unless it's reading from a pipe, uses
 buffered reads.  When reading from stdin, upon reading a newline, it
 must seek the input file pointer back to the offset of the newline to
 avoid potentially stealing input from other programs. 
 
 This seeking backward does not work when applied to named pipes on 
 FreeBSD 5.[34], though there is no indication that it fails.
 
 I don't know how FreeBSD implements named pipes, but they're not pipes:
 lseek doesn't return failure when applied to them.
 
 So the following happens: bash reads 128 bytes from the named pipe
 connected to the process running `cat /etc/passwd'.  It reads 74 bytes
 or so (on my system), finds a newline, returns the newline, and
 attempts to seek backwards 54 bytes.  lseek appears to work and sets
 the file offset to 74.  The next read, however, gets another 128 bytes
 of data beginning at offset 129.  You end up missing large chunks of
 the file. 
 
 It worked on FreeBSD 4.x because that version had /dev/fd, and so bash
 didn't use named pipes.  FreeBSD 5 doesn't support /dev/fd by default
 for any file descriptors other than 0, 1, and 2. 
 
 Chet