Re: Bash process substitution
On Jan 22 18:46, Dave wrote: Is process substitution expected to work in 1.7.1? Here's what I tried: kilr...@minime ~ $ uname -a CYGWIN_NT-5.1 MINIME 1.7.1(0.218/5/3) 2009-12-07 11:48 i686 Cygwin kilr...@minime ~ $ echo LOG:bananas | tee file.txt LOG:bananas kilr...@minime ~ $ cat file.txt LOG:bananas kilr...@minime ~ $ echo LOG:bananas | tee (grep ^LOG: file.txt) LOG:bananas tee: /dev/fd/63: Bad file descriptor I'm not quite sure how this command works under the hood, but it's possible that this can't work in Cygwin due to a restriction in Windows. In contrast to Unix, you can't call open(pipe_fd, O_RDONLY) if pipe_fd is the write side of a pipe and vice versa. If bash's process substitution relies on that, it's simply not possible. Dunno if there is a way to implement this using some hackery, of course... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bash process substitution
On Jan 23 12:07, Corinna Vinschen wrote: On Jan 22 18:46, Dave wrote: Is process substitution expected to work in 1.7.1? Here's what I tried: kilr...@minime ~ $ uname -a CYGWIN_NT-5.1 MINIME 1.7.1(0.218/5/3) 2009-12-07 11:48 i686 Cygwin kilr...@minime ~ $ echo LOG:bananas | tee file.txt LOG:bananas kilr...@minime ~ $ cat file.txt LOG:bananas kilr...@minime ~ $ echo LOG:bananas | tee (grep ^LOG: file.txt) LOG:bananas tee: /dev/fd/63: Bad file descriptor I'm not quite sure how this command works under the hood, but it's possible that this can't work in Cygwin due to a restriction in Windows. In contrast to Unix, you can't call open(pipe_fd, O_RDONLY) if pipe_fd is the write side of a pipe and vice versa. If bash's process substitution relies on that, it's simply not possible. Dunno if there is a way to implement this using some hackery, of course... Hang on, this is a EBADF. Looks like bash tries to access a file descriptor which isn't available (anymore). Eric, would you mind to have a look into bash to examine what's going on here? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bash process substitution
On Sat, Jan 23, 2010 at 12:07:19PM +0100, Corinna Vinschen wrote: On Jan 22 18:46, Dave wrote: Is process substitution expected to work in 1.7.1? Here's what I tried: kilr...@minime ~ $ uname -a CYGWIN_NT-5.1 MINIME 1.7.1(0.218/5/3) 2009-12-07 11:48 i686 Cygwin kilr...@minime ~ $ echo LOG:bananas | tee file.txt LOG:bananas kilr...@minime ~ $ cat file.txt LOG:bananas kilr...@minime ~ $ echo LOG:bananas | tee (grep ^LOG: file.txt) LOG:bananas tee: /dev/fd/63: Bad file descriptor I'm not quite sure how this command works under the hood, but it's possible that this can't work in Cygwin due to a restriction in Windows. In contrast to Unix, you can't call open(pipe_fd, O_RDONLY) if pipe_fd is the write side of a pipe and vice versa. If bash's process substitution relies on that, it's simply not possible. Dunno if there is a way to implement this using some hackery, of course... I thought this construction used a fifo under the hood. That could point to YA problem with my fifo implementation. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bash process substitution
Is process substitution expected to work in 1.7.1? Here's what I tried: kilr...@minime ~ $ uname -a CYGWIN_NT-5.1 MINIME 1.7.1(0.218/5/3) 2009-12-07 11:48 i686 Cygwin kilr...@minime ~ $ echo LOG:bananas | tee file.txt LOG:bananas kilr...@minime ~ $ cat file.txt LOG:bananas kilr...@minime ~ $ echo LOG:bananas | tee (grep ^LOG: file.txt) LOG:bananas tee: /dev/fd/63: Bad file descriptor kilr...@minime ~ $ cat file.txt --- I'm actually trying to do something like: socat - /dev/ttyS0,raw,echo=0 | tee \ (grep ^LOG: --line-buffered | socat - UDP:localhost:1234) but am getting the same error as the simpler example. And if anyone knows whether STDIN would make it out of /dev/ttyS0, (or how to get that) I'd appreciate the hint. Thanks, Dave. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
bash process substitution hangs with ssh
Running the following command: cat (ssh remotemachine cat remotefile) *hangs* on cygwin bash while working on linux bash. Note though that even on cygwin, the individual pieces seem to work, i.e.: ssh remotemachine cat remotefile and cat (cat localfile) both work. But combining the two fails. Any thoughts on what may be wrong here? -- View this message in context: http://old.nabble.com/bash-process-substitution-hangs-with-ssh-tp26983912p26983912.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: bash process substitution hangs with ssh
aputerguy writes: ssh remotemachine cat remotefile Note typo above. Should be: ssh remotemachine cat remotefile -- View this message in context: http://old.nabble.com/bash-process-substitution-hangs-with-ssh-tp26983912p26983920.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: bash process substitution hangs with ssh
The problem also seems to affect named pipes: i.e. $ mkfifo mypipe $ ssh remotemachine cat remotefile mypipe Segmentation fault (core dumped) But $ cat localfile mypipe works (note in both cases I read the pipe in another terminal using: cat mypipe) -- View this message in context: http://old.nabble.com/bash-process-substitution-hangs-with-ssh-tp26983912p26983954.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: bash process substitution hangs with ssh
OK I got it to work by using 'ssh -n' since I guess otherwise it was waiting to read from stdin. Not sure though why it works without '-n' in Linux... -- View this message in context: http://old.nabble.com/bash-process-substitution-hangs-with-ssh-tp26983912p26983985.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: bash process substitution hangs with ssh
And interestingly, the mkfifo version still dumps core even with 'ssh -n' I'm confused... -- View this message in context: http://old.nabble.com/bash-process-substitution-hangs-with-ssh-tp26983912p26983991.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
more on Re: bash process substitution (list) [spot the difference]
I am exploring how process substitution works on Cygwin. I have scripts
which run fine on Linux but not on Windows XP.
Why does one of these scripts produce an error and the other does not?
Script #1:
$ cat a
#!/bin/bash
function f()
{
echo $1
cat $1
}
f (echo OK)
$ ./a
/proc/self/fd/63
OK
Script #2:
$ cat b
#!/bin/bash
function f()
{
ls -l $1
cat $1
}
f (echo OK)
$ ./b
lrwxrwxrwx 1 luser None 0 May 29 15:49 /proc/self/fd/63 - pipe:[1728]
cat: /proc/self/fd/63: No such file or directory
Thanks,
--binkley
http://binkley.blogspot.com/
--
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/
Re: more on Re: bash process substitution (list) [spot the difference]
B. K. Oxley (binkley) wrote:
I am exploring how process substitution works on Cygwin. I have scripts
which run fine on Linux but not on Windows XP.
Why does one of these scripts produce an error and the other does not?
Script #1:
$ cat a
#!/bin/bash
function f()
{
echo $1
cat $1
}
f (echo OK)
$ ./a
/proc/self/fd/63
OK
Script #2:
$ cat b
#!/bin/bash
function f()
{
ls -l $1
cat $1
}
f (echo OK)
$ ./b
lrwxrwxrwx 1 luser None 0 May 29 15:49 /proc/self/fd/63 - pipe:[1728]
cat: /proc/self/fd/63: No such file or directory
With the exception of a slight bit of file name conversion, I get the same
result as you do with Cygwin when I run on Linux (FC4):
# /tmp/a
/dev/fd/63
OK
# /tmp/b
lr-x-- 1 lhall lhall 64 May 29 23:26 /dev/fd/63 - pipe:[916212]
cat: /dev/fd/63: No such file or directory
This is using your scripts verbatim.
--
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
216 Dalton Rd. (508) 893-9889 - FAX
Holliston, MA 01746
_
A: Yes.
Q: Are you sure?
A: Because it reverses the logical flow of conversation.
Q: Why is top posting annoying in email?
--
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/
Re: more on Re: bash process substitution (list) [spot the difference]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to B. K. Oxley (binkley) on 5/29/2007 9:05 PM:
Why does one of these scripts produce an error and the other does not?
function f()
{
echo $1
shell builtin, and it does not touch the fifo (try replacing this with
/bin/echo to see the difference)
cat $1
so the fifo is still available
function f()
{
ls -l $1
external process, which calls exit() and thus closes the only read handle
on the fifo. At which point, the writer is closed since no reader exists.
cat $1
the fifo no longer exists, so the error is correct
If you need the fifo to persist over several external commands, you need
to use a shell grouping construct or an exec so that the shell holds a
handle to the fifo for the duration of the shell function. And this is
not cygwin specific.
- --
Don't work too hard, make some time for fun as well!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGXPKR84KuGfSFAYARAlZuAKDVNUr7vzs2lRFjcaS0201C+uu7IgCfUK81
vVzTHO2X4g0SKg2CBK126hk=
=UL94
-END PGP SIGNATURE-
--
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/
bash process substitution (list) possible bug
test script /tmp/foo, and test run showing the problem: ~ $ cat /tmp/foo #!/bin/bash file=$1 TMPF=$(mktemp /tmp/XX) set -x test -s $file || echo $? cp $file $TMPF cat $TMPF ~ $ /tmp/foo (echo ABC) + test -s /proc/self/fd/63 + echo 1 1 + cp /proc/self/fd/63 /tmp/RIV456 + cat /tmp/RIV456 ABC ~ $ date;uname -a Sat Mar 10 09:09:22 CST 2007 CYGWIN_NT-5.0 argon 1.5.24(0.156/4/2) 2007-01-31 10:57 i686 Cygwin ~ $ cygcheck -c|grep bash bash 3.2.9-11 OK ~ $ The 'test -s $file' in the test run above should return 0. -- thanks, Tom linux test case: --v-v--C-U-T---H-E-R-E-v-v-- ~ $ cat /tmp/foo #!/bin/bash file=$1 TMPF=$(mktemp /tmp/XX) set -x test -s $file || echo $? cp $file $TMPF cat $TMPF ~ $ /tmp/foo (echo ABC) + test -s /dev/fd/63 + cp /dev/fd/63 /tmp/1HLI14 + cat /tmp/1HLI14 ABC ~ $ date;uname -a Sat Mar 10 08:38:30 CST 2007 Linux localhost.localdomain 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 i686 i386 GNU/Linux ~ $ -- 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/
Re: bash process substitution (list) possible bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] volunteer cygwin bash maintainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF8zdr84KuGfSFAYARAnUYAKCW2DUrKcY5FMpz7DXTjErLE4CnNQCdEZWA xDpzpb8nzuShkWgw2GJi/Yo= =FcmH -END PGP SIGNATURE- -- 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/
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/XX) 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/
bash process substitution [Was: Ref http://www.cygwin.com/ml/cygwin/2005-04/msg00651.html]
[Picking a better subject line] From: Anders Brandén Hi, referring http://www.cygwin.com/ml/cygwin/2005-04/msg00651.html I have a comment, the problem seems to be more of a general kind(files that doesn't exist already don't get created for writing) as these things happen on my Cygwin system (running under Server 2003): There is a distinct difference between disk files and pipes. This is the new thing I've found, note that without the pipe(i.e. | cat) the command runs just fine: tar -cf /proc/self/fd/1 syntax.c | cat tar: /proc/self/fd/1: Cannot write: Bad file descriptor tar: Error is not recoverable: exiting now Here, the pipe operator tells bash to create a pipe and use the write end of that pipe as tar's stdout, so tar is started with fd 1 as a pipe. Inside tar, cygwin is apparently getting the read end of /proc/self/fd/1 instead of the write end, leading to tar complaining about a write failure when it tries to put output on a read-only fd. and this is what happens on my system with the command referred in the link above, note that the error messages are the same! $ tar -cf (cat) syntax.c tar: /proc/self/fd/63: Cannot write: Bad file descriptor tar: Error is not recoverable: exiting now Here, bash creates a pipe for the command substitution, which is named /proc/self/fd/63, then we are once again at the point where tar opens the read end of fd 63 instead of the write end, explaining the same error as before. Both of these commands effectively creates a temporary file for both reading and writing and that seems to be the problem, this command runs just fine because I create a file for writing: $ tar -cf (cat) syntax.c 63temp Whoa. Your explanation has a hole. Here, bash handles the process substitution first, creating a pipe (fd 63), of which the write end will be handed to tar and the read end handed to cat. Then bash does the redirection, opening the file temp (whether pre-existing or not) for writing as fd 63. Now cat still has the read end of the pipe, but the write end has been lost (so cat becomes a no-op), and tar now has a file rather than a pipe at /proc/self/fd/63, and cygwin correctly treats a file open for writing as a writable fd. and, once created, this command runs fine too, however note that the redirection of input also redirects output though it really shouldn't (try it without having the temp file first, and then with an empty temp file and check the contents afterward): $ tar -cf (cat) syntax.c 63temp Similar to above - cat is a no-op process, since you threw away the write end of the pipe, and now tar is handed a file descriptor opened for reading. If tar is able to write to /proc/self/fd/63, then that might be a cygwin limitation where files are treated as read-write instead of read-only. So without the temp file, this fails every time: $ tar -cf (cat) syntax.c 63temp 63temp bash: temp: No such file or directory The first redirection (63temp) fails if temp does not exist, because POSIX requires read redirection to fail if the file does not exist. But this always works: $ tar -cf (cat) syntax.c 63temp 63temp Here, the write redirection creates the file temp if it did not already exist, then the read redirection grabs the same file for reading; and you are back to my earlier comment that if cygwin lets tar write to a read-only file descriptor, then that is a bug/limitation of cygwin. Writing to temp gives (cat temp) nothing to read: $ tar -cf (cat temp) syntax.c 63temp 63temp This is racy. It is not guaranteed whether cat will parse its arguments and try to open temp for reading before bash has finished handling its redirections and created temp for writing; then reopened temp for reading. You cannot reliably predict what will happen here. $ tar -cf (cat temp) syntax.c 63temp 63temp Likewise racy. Don't try it - it won't be predictable. However there is obviously also something wrong with the redirection of standard input for (cat) because I get no output with either of these statements even after the temp file is created (writing to temp2 while attempting to read from temp): $ tar -cf (cat) syntax.c 63temp2 63temp Well of course - read my earlier comments - bash is hosing the write end of the pipe, so cat is reading from nowhere, and will print nothing. $ tar -cf (cat) syntax.c 63temp 63temp2 So only these gives the expected output: $ tar -cf (cat temp) syntax.c 63temp2 63temp I don't know how you can call that expected, since it is trying to rely on a data race. $ tar -cf (cat temp) syntax.c 63temp 63temp2 Hope this helps in pinpointing the problem. What problem? The original mail was about cygwin treating /proc/self/fd/nnn as read-only if it refers to a pipe, whether or not the process was handed the write end of that pipe; but the last half of your email has been complaining about fds referring to files and not pipes. -- Eric Blake
Re: Bash Process Substitution
On Thu, Apr 14, 2005 at 03:58:13AM -0400, Lev S Bishop wrote: Process substitution in bash is not working for me currently. I'm pretty certain it worked at some point in the past (maybe about 6 months ago). For example: $ cat ( echo hello) hangs, ignoring ^C, kill -9, and requiring kill -f on the cat process. This is working (for me at least) in cygwin 1.5.16. However, since it uses fifos, it is possible that it may still be flaky. I have more work to do in fifos when I get a tuit. cgf -- 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/
Bash Process Substitution
Process substitution in bash is not working for me currently. I'm pretty certain it worked at some point in the past (maybe about 6 months ago). For example: $ cat ( echo hello) hangs, ignoring ^C, kill -9, and requiring kill -f on the cat process. Reading the bash manual, it seems bash can use either /dev/fd or named pipes as the underlying mechanism for process substitution. My understanding is that cygwin has recently gained some level of support for named pipes but that they aren't fully working (is this true?). Perhaps in the past, bash used the /dev/fd method but now it sees these named pipes and tries to use those, but chokes due to the incomplete implementation of the latter? Some evidence that this is the case: $ echo ( echo) /tmp/sh-np-197572444 $ ls -l /tmp/sh-np-197572444 prw--- 1 Lev None 102 Apr 14 03:42 /tmp/sh-np-197572444 So it looks to be using a fifo in /tmp I tried adding a symlink /dev/fd like on my linux box, but this didn't help: $ ls -l /dev/fd lrwxrwxrwx 1 Lev None 13 Apr 13 21:54 /dev/fd - /proc/self/fd So, if my guess is correct, maybe there is some way to convince bash to ignore the fifo possibility and just use /dev/fd, as it presumably did in the past? Results of the above commands on a linux box, for comparison purposes: $ cat ( echo hello) hello $ echo ( echo) /dev/fd/63 $ ls -l /dev/fd lrwxrwxrwx1 root root 15 Oct 5 2001 /dev/fd - ../proc/self/fd So it appears that on the linux box it is not using a fifo. Thanks for any insight, Lev cygcheck -s -v -r output attached Cygwin Configuration Diagnostics Current System Time: Thu Apr 14 03:52:07 2005 Windows XP Home Edition Ver 5.1 Build 2600 Service Pack 2 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin .\ C:\cygwin\bin C:\cygwin\usr\X11R6\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Program Files\ProENGINEER Student Edition\bin c:\Program Files\ATI Technologies\ATI Control Panel c:\Program Files\Common Files\GTK\2.0\bin c:\MATLABR11\bin c:\Program Files\SSH Communications Security\SSH Secure Shell c:\WINDOWS\System32\ C:\cygwin\bin C:\cygwin\usr\X11R6\bin\ Output from C:\cygwin\bin\id.exe (nontsec) UID: 1007(Lev) GID: 513(None) 513(None) Output from C:\cygwin\bin\id.exe (ntsec) UID: 1007(Lev) GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS CYGWIN = `server' HOME = `C:\cygwin\home\Lev' MAKE_MODE = `unix' PWD = `/home/Lev' USER = `Lev' !EXITCODE = `' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\Lev\Application Data' CLASSPATH = `C:\Program Files\Java\j2re1.4.2_03\lib\ext\QTJava.zip' COLLECTIONID = `COL8143' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `RAAJSGDH' COMSPEC = `C:\WINDOWS\system32\cmd.exe' CVS_RSH = `/bin/ssh' CYGWIN_ROOT = `\cygwin' DISPLAY = `127.0.0.1:0.0' FP_NO_HOST_CHECK = `NO' HMSERVER = `https://wwss1pro.cce.hp.com/wuss/servlet/WUSSServlet' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\Lev' HOSTNAME = `raajsgdh' ITEMID = `dj-22741-10' LANG = `2057' LOGNAME = `Lev' LOGONSERVER = `\\RAAJSGDH' LS_COLORS = `no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:ex=01;33:*~=05;31:*.mtxt=05;31:*.ndx=05;31:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.btm=01;32:*.bat=01;32:*.c=01;36:*.h=01;36:*.pl=01;36:*.pm=01;36:*.cgi=01;36:*.java=01;36:*.html=01;36:*.tar=01;31:*.tgz=01;31:*.gz=01;31:*.tgz=01;31:*.bz2=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.jpg=01;35:*.jpeg=01;35:*.JPG=01;35:*.gif=01;35:*.GIF=01;35:*.bmp=01;35:*.BMP=01;35:*.xbm=01;35:*.ppm=01;35:*.xpm=01;35:*.tif=01;35:' MANPATH = `:/usr/ssl/man:/usr/X11R6/man' NUMBER_OF_PROCESSORS = `1' OS = `Windows_NT' OSVER = `winXPH' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.tcl' PKG_CONFIG_PATH = `/usr/X11R6/lib/pkgconfig' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 6 Model 11 Stepping 1, GenuineIntel' PROCESSOR_LEVEL = `6' PROCESSOR_REVISION = `0b01' PROGRAMFILES = `C:\Program Files' PROMPT = `$P$G' PS1 = `\[\033]0;\w\007 [EMAIL PROTECTED] \[\033[33m\w\033[0m\] $ ' QTJAVA = `C:\Program Files\Java\j2re1.4.2_03\lib\ext\QTJava.zip' SESSIONID = `1102556474045htx694c2ea0b:101105131c0:-23bf' SESSIONNAME = `Console' SHLVL = `3' SSH_AGENT_PID = `3304' SSH_AUTH_SOCK = `/tmp/ssh-GAHQJz3256/agent.3256' SWUTVER = `1.0.18.30716' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINDOWS' TEMP = `c:\DOCUME~1\Lev\LOCALS~1\Temp' TERM = `xterm' TERMCAP = `xterm-r6|xterm|xterm X11R6
RE: Bash Process Substitution
I tried building bash from the source package, and then it uses either /dev/fd (if I have that as a symlink) or /proc/self/fd (if I don't), rather than the fifo that the binary package uses. So perhaps whoever built the binary package didn't have /proc/self/fd for whatever reason? With my built bash.exe, process substitution seems to work for input: $ echo (ls) /proc/self/fd/63 $ cat (echo hi) hi But not for output: $ tar -cf (cat) syntax.c tar: /proc/self/fd/63: Cannot open: Permission denied tar: Error is not recoverable: exiting now I'm not sure how there can be a permissions problem or what to do about it if there really is one, given that as I understand it the /proc/self/fd/63 is effectively a symlink to one end of something returned from pipe(2). Lev -- 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/
Re: Bash Process Substitution
Lev S Bishop wrote: rather than the fifo that the binary package uses. So perhaps whoever built the binary package didn't have /proc/self/fd for whatever reason? If I'm not mistaken /proc/pid/fd capabilty was added 2005-02-01. The current bash package (2.05b-16) was released 2003-10-23. (the test version -17 was released 2004-11-22.) So it was quite impossible for the person who built bash to have that feature. Brian -- 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/
Re: Bash Process Substitution
Brian Dessent wrote: If I'm not mistaken /proc/pid/fd capabilty was added 2005-02-01. The current bash package (2.05b-16) was released 2003-10-23. (the test version -17 was released 2004-11-22.) So it was quite impossible for the person who built bash to have that feature. Thanks for this piece of info, Brian. It saved me from barking up completely the wrong tree. Things are becoming clearer. I guess what happened is that the binary build of bash used fifos, which have only ever been partially implemented in cygwin, and although at one point in the past they worked well enough for process substitution's needs, in the meantime the implementation has changed sufficiently to break that. The version of bash that I built uses /proc/self/fd, which is a brand spanking new feature that also doesn't quite work in terms of process substitution on output. (Is this all plausible?) Its either that, or process substituion never worked at all on cygwin, my memory is completely flawed, and these nifty scripts I have here were copied from a non-cygwin box. (This is certainly plausible.) Lev -- 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/
Re: Bash Process Substitution
On Apr 14 08:04, Lev S Bishop wrote: I tried building bash from the source package, and then it uses either /dev/fd (if I have that as a symlink) or /proc/self/fd (if I don't), rather than the fifo that the binary package uses. So perhaps whoever built the binary package didn't have /proc/self/fd for whatever reason? The bash package has been built before /proc/pid/fd came into existance. With my built bash.exe, process substitution seems to work for input: $ echo (ls) /proc/self/fd/63 $ cat (echo hi) hi But not for output: $ tar -cf (cat) syntax.c tar: /proc/self/fd/63: Cannot open: Permission denied tar: Error is not recoverable: exiting now I'm not sure how there can be a permissions problem or what to do about it if there really is one, given that as I understand it the /proc/self/fd/63 is effectively a symlink to one end of something returned from pipe(2). It's probably the wrong end. In the Linux kernel there's some magic going on which we can't reproduce in Cygwin so far. Trying to open an existing pipe for writing or reading opens apparently exactly the right end of the pipe under Linux. On Windows, you only get the exact end of the pipe which is already available to the current process. That's the read side of the pipe, AFAICS, and that doesn't allow writing. This explains the Permission denied. HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- 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/
Re: Bash Process Substitution
Corina wrote: In the Linux kernel there's some magic going on which we can't reproduce in Cygwin so far. Trying to open an existing pipe for writing or reading opens apparently exactly the right end of the pipe under Linux. On Windows, you only get the exact end of the pipe which is already available to the current process. That's the read side of the pipe, AFAICS, and that doesn't allow writing. This explains the Permission denied. Interesting. Looking in function process_substitute in subst.c, I can see that bash tries to swap ends of the pipe depending on whether its a (cmd) or a (cmd) substitution. Lev -- 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/
Re: Bash Process Substitution
On Thu, 14 Apr 2005, Lev S Bishop wrote: Corina wrote: ^^ Sorry, Corinna. -- 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/
