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 ~
$
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 |
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
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
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:
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
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:
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
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
-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
-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
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
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
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
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
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
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
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
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:
19 matches
Mail list logo
