On Mon, Apr 21, 2014 at 02:31:12PM -0400, John Baldwin wrote: > On Thursday, April 17, 2014 2:50:01 pm Konstantin Belousov wrote: > > The following reply was made to PR amd64/188699; it has been noted by GNATS. > > > > From: Konstantin Belousov <kostik...@gmail.com> > > To: John Allman <free...@hugme.org> > > Cc: freebsd-gnats-sub...@freebsd.org > > Subject: Re: amd64/188699: Dev tree > > Date: Thu, 17 Apr 2014 21:44:52 +0300 > > > > On Wed, Apr 16, 2014 at 05:32:45PM +0000, John Allman wrote: > > > This is how to reproduce it: > > > > > > Fresh install of 10 on AMD 64 > > > install bash `pkg install bash` > > > Switch to bash `bash` > > > push a here document into a loop: `while true ; do echo; done< <(echo > > "123")` > > > receive an error: "-su: /dev/fd/62: No such file or directory" > > > > > > I'm sorry I haven't been able to research this any further. I found how > > while working on some important matters. As I mentioned the above works > > fine in all > previous versions of FreeBSD up until 10. > > > >How-To-Repeat: > > > Fresh install > > > pkg install bash > > > bash > > > while true; do echo foo done< <(echo "123") > > > > > > -su: /dev/fd/62: No such file or directory > > > > So do you have fdescfs mounted on /dev/fd on the machine where the > > test fails ? It works for me on head, and if unmounted, I get the > > same failure message as yours. I very much doubt that it has anything > > to do with a system version. > > Question I have is why is bash deciding to use /dev/fd/<n> and require > fdescfs? On older releases bash uses named pipes for this instead.
The aclocal.m4 contains the test which verifies the presence and usability of /dev/fd/n for n>=3 on the _build_ host. The result of the test is used on the installation host afterward. Such kinds of bugs are endemic in our ports, but apparently upstreams are guilty too.
pgpUx4zuqtj1y.pgp
Description: PGP signature