This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: bash process substitution "<(list)"
On Sat 3/10/07 15:55 MST Eric Blake wrote:
> According to Tom Rodman on 3/10/2007 8:14 AM:
> > ~ $ /tmp/foo <(echo ABC)
> > + test -s /proc/self/fd/63
> > + echo 1
> >
> > The 'test -s "$file"' in the test run above should return 0.
>
> How do you figure? pipes are special file types, and st_size is
> unspecified in a stat() call on a pipe, so the -s test is unreliable in
> the first place. Not to mention there is an inherent race in your script
> (did the 'echo ABC' process run before or after the 'test -s
> /proc/self/fd/63' builtin of the script?). I maintain that there is no
> bug except in your script.
Coming at this from a strictly end user view point, not having
read the "process substitution" bash man page section carefully I
wrongly assumed the <(list) mechanism in bash would support
the test -s. Thanks for straightening me out. So the key issue
is that we're dealing w/named pipes, not files.
--
*thanks*,
Tom
--
PS
It's interesting that the "test -s" works in the linux I have for
the "full pipe" case, and for this "empty pipe" case:
~ $ cat /tmp/foo
#!/bin/bash
file=$1
TMPF=$(mktemp /tmp/XXXXXX)
set -x
test -s "$file" || echo $?
cp $file $TMPF
cat $TMPF
~ $ /tmp/foo <(true)
+ test -s /dev/fd/63
+ echo 1
1
+ cp /dev/fd/63 /tmp/WJvtLk
+ cat /tmp/WJvtLk
~ $ date;uname -a
Sat Mar 10 17:53:22 CST 2007
Linux myhost.blah.nil 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 GNU/Linux
I did not run any of these test cases more than two or three
times, maybe after repeated tries, that race condition would
come into play.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/