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/
