* Re: exit value of intermediate program in pipe
@ 1998-05-05 11:54 Bernd Eggink
0 siblings, 0 replies; 12+ messages in thread
From: Bernd Eggink @ 1998-05-05 11:54 UTC (permalink / raw)
To: zsh-users
Date: Tue, 5 May 1998 13:39:33 +0200 (DFT)
From: Bernd Eggink <rz2a022@uni-hamburg.de>
To: zsh-users@math.gatech.edu
Subject: Re: exit value of intermediate program in pipe
On Mon, 4 May 1998, Bart Schaefer wrote:
> On May 4, 2:03pm, Bernd Eggink wrote:
> } Subject: Re: exit value of intermediate program in pipe
> }
> } Bart Schaefer wrote:
> }
> } > } In ksh, the normal way to kill a coproc is
> } > }
> } > } exec 3<&p 3<-
> } >
> } > Anyway, I'm curious about that ksh-ism, because
> } > it closes the coproc's *output*, not it's input
> }
> } Huh? Of course it closes it's input; that's what < means!
>
> Think about it a moment. If you do
>
> cat <&p
>
> what happens? The input _of cat_ is connected to the _output_ of the
> coproc, right? So if you do
>
> exec 3<&p
>
> then what is descriptor 3? That better be the _output_ of the coproc,
> too, or ksh is doing some pretty funky special casing.
>
> So perhaps you meant to say
>
> exec 3>&p 3>-
Hm, I admit that I never tried this in zsh... In fact, it works
like this in zsh, but exactly the OTHER way round in ksh. In ksh
3<&p means "duplicate the coproc input to unit 3". IMHO this is
more consistent and intuitive than what zsh does.
After looking into the doc, I even suspect that this may be a bug...
Quoting from chapter 6, "redirection":
<&p
>&p The input/output from/to the coprocess is moved to the
standard input/output.
If 'input' corresponds to <&p, this is fact what ksh does and what
zsh DOESN'T!
Regards,
Bernd
--
Bernd Eggink
Regionales Rechenzentrum der Uni Hamburg
eggink@rrz.uni-hamburg.de
http://www.rrz.uni-hamburg.de/eggink/BEggink.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: exit value of intermediate program in pipe
1998-05-04 15:59 ` Bart Schaefer
@ 1998-05-05 11:39 ` Bernd Eggink
0 siblings, 0 replies; 12+ messages in thread
From: Bernd Eggink @ 1998-05-05 11:39 UTC (permalink / raw)
To: Bart Schaefer; +Cc: Bernd Eggink, zsh-users
On Mon, 4 May 1998, Bart Schaefer wrote:
> On May 4, 2:03pm, Bernd Eggink wrote:
> } Subject: Re: exit value of intermediate program in pipe
> }
> } Bart Schaefer wrote:
> }
> } > } In ksh, the normal way to kill a coproc is
> } > }
> } > } exec 3<&p 3<-
> } >
> } > Anyway, I'm curious about that ksh-ism, because
> } > it closes the coproc's *output*, not it's input
> }
> } Huh? Of course it closes it's input; that's what < means!
>
> Think about it a moment. If you do
>
> cat <&p
>
> what happens? The input _of cat_ is connected to the _output_ of the
> coproc, right? So if you do
>
> exec 3<&p
>
> then what is descriptor 3? That better be the _output_ of the coproc,
> too, or ksh is doing some pretty funky special casing.
>
> So perhaps you meant to say
>
> exec 3>&p 3>-
Hm, I admit that I never tried this in zsh... In fact, it works
like this in zsh, but exactly the OTHER way round in ksh. In ksh
3<&p means "duplicate the coproc input to unit 3". IMHO this is
more consistent and intuitive than what zsh does.
After looking into the doc, I even suspect that this may be a bug...
Quoting from chapter 6, "redirection":
<&p
>&p The input/output from/to the coprocess is moved to the
standard input/output.
If 'input' corresponds to <&p, this is fact what ksh does and what
zsh DOESN'T!
Regards,
Bernd
--
Bernd Eggink
Regionales Rechenzentrum der Uni Hamburg
eggink@rrz.uni-hamburg.de
http://www.rrz.uni-hamburg.de/eggink/BEggink.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: exit value of intermediate program in pipe
1998-05-04 12:03 ` Bernd Eggink
@ 1998-05-04 15:59 ` Bart Schaefer
1998-05-05 11:39 ` Bernd Eggink
0 siblings, 1 reply; 12+ messages in thread
From: Bart Schaefer @ 1998-05-04 15:59 UTC (permalink / raw)
To: Bernd Eggink; +Cc: zsh-users
On May 4, 2:03pm, Bernd Eggink wrote:
} Subject: Re: exit value of intermediate program in pipe
}
} Bart Schaefer wrote:
}
} > } In ksh, the normal way to kill a coproc is
} > }
} > } exec 3<&p 3<-
} >
} > Anyway, I'm curious about that ksh-ism, because
} > it closes the coproc's *output*, not it's input
}
} Huh? Of course it closes it's input; that's what < means!
Think about it a moment. If you do
cat <&p
what happens? The input _of cat_ is connected to the _output_ of the
coproc, right? So if you do
exec 3<&p
then what is descriptor 3? That better be the _output_ of the coproc,
too, or ksh is doing some pretty funky special casing.
So perhaps you meant to say
exec 3>&p 3>-
??
} > Can somebody out there who has ksh tell me whether
} >
} > cat |&
} > echo >&p
} >
} > causes cat to exit? That is, does redirection to the coproc make the
} > coproc input no longer available to any other process?
}
} Yes, it does.
OK, then zsh either has a bug or an undocumented feature. If zsh did as
ksh does, then zsh's coproc would get EOF as soon as the first thing you
redirected to it exited.
} > } You can have more than one coprocs at a time. Just copy the fd's:
} > }
} > } coproc f
} > } exec 3>&p 4<&p # or whatever numbers you like
} > } coproc g
} >
} > Right; if you do that, then my "coproc exit" trick won't stop the first
} > coproc, because its input has already been dup'd once and the dup is
} > kept open.
}
} So in this case 'kill' seems to be the only way to get rid of the first
} n-1 coprocs...
No, that's not true. Once you've run "coproc g" then you can get "f" to
see EOF by simply closing fd 3. It's only the coproc descriptor that gets
copied rather than "moved" when you redirect it.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: exit value of intermediate program in pipe
1998-05-04 11:42 ` Bart Schaefer
@ 1998-05-04 12:03 ` Bernd Eggink
1998-05-04 15:59 ` Bart Schaefer
0 siblings, 1 reply; 12+ messages in thread
From: Bernd Eggink @ 1998-05-04 12:03 UTC (permalink / raw)
To: Bart Schaefer; +Cc: zsh-users
Bart Schaefer wrote:
> On May 4, 11:43am, Bernd Eggink wrote:
> } Subject: Re: exit value of intermediate program in pipe
> }
> } Sweth Chandramouli wrote:
> } > > The last problem is that grep won't exit until it sees EOF on its stdin,
> } > > but >&p dups the coproc input without actually closing it.
> }
> } In ksh, the normal way to kill a coproc is
> }
> } exec 3<&p 3<-
>
> Do you mean 3<&- or is <- magic in ksh? (In zsh, <&- is magic but it only
> works on stdin, it doesn't take a digit to the left.)
>
> } because just killing the job doesn't close the file descriptor.
>
> It may not in zsh either. Anyway, I'm curious about that ksh-ism, because
> it closes the coproc's *output*, not it's input
Huh? Of course it closes it's input; that's what < means!
> -- so it's assuming that
> the coproc will die on a "broken pipe" signal, which isn't necessarily
> true. (As my "yes" example demonstrates, closing the input won't always
> work either, but presumably you don't normally coproc something that is
> going to ignore its input.)
>
> My "coproc exit" hack works because it closes the old coproc input so as
> to not leak the descriptor. But it wouldn't have been incorrect for it
> to leave it open, as far as documented behavior goes (which isn't far).
>
> } In
> } zsh-3.1.3, this doesn't work (a bug, IMHO), but you can kill the job
> } without getting problems.
>
> If you kill the job, you may lose some of its output. The only correct
> way is to close the input and let it die in its own good time.
That's what I said - but it doesn't work.
> Can somebody out there who has ksh tell me whether
>
> cat |&
> echo >&p
>
> causes cat to exit? That is, does redirection to the coproc make the
> coproc input no longer available to any other process?
Yes, it does.
[...]
>
> That is, zsh will re-open the same coproc input as often as you like,
> and never closes it until you start a new coproc. Does ksh do that?
No.
> } You can have more than one coprocs at a time. Just copy the fd's:
> }
> } coproc f
> } exec 3>&p 4<&p # or whatever numbers you like
> } coproc g
>
> Right; if you do that, then my "coproc exit" trick won't stop the first
> coproc, because its input has already been dup'd once and the dup is
> kept open.
So in this case 'kill' seems to be the only way to get rid of the first
n-1 coprocs...
--
Bernd Eggink
Regionales Rechenzentrum der Uni Hamburg
eggink@rrz.uni-hamburg.de
http://www.rrz.uni-hamburg.de/eggink/BEggink.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: exit value of intermediate program in pipe
1998-05-04 9:43 ` Bernd Eggink
@ 1998-05-04 11:42 ` Bart Schaefer
1998-05-04 12:03 ` Bernd Eggink
0 siblings, 1 reply; 12+ messages in thread
From: Bart Schaefer @ 1998-05-04 11:42 UTC (permalink / raw)
To: zsh-users
On May 4, 12:54am, Sweth Chandramouli wrote:
} Subject: Re: Re: exit value of intermediate program in pipe
}
} the FAQ did have the fact that |& uses the csh syntax, which i had missed,
} but has no reference that i could find to >&p or how to use it, and i
} think that my (wrong) interpretation was reasonable based on the description
} in the manpage.
I've already bugged zsh-workers about the manpage deficiency.
} as far as i can tell, though, zsh coproc just swallows the eof, since doing
} an
} echo "^D" >&p
} should otherwise have the same effect as "coproc exit", but doesn't. and
} _that_ is something that i _would_ consider a bug.
No, that's not a bug; ctrl-D only means EOF on tty devices; sending one
down any other kind of stream is just sending a byte with the value \004.
This isn't DOS where a magic character in any text stream is read as EOF.
} > I think { /bin/blah >>(grep -v bar) } is a lot nicer, don't you?
}
} true, but it still ends when the first process ends
No, not quite; it gets EOF when the first process ends, but if it doesn't
happen to be a program that exits when it gets EOF on stdin, it'll just
keep running.
echo goodbye >>(yes hello)
produces an unstoppable and rather difficult to kill stream of hellos on
your terminal. On some OSs even exiting the tty session many not get rid
of it (linux 2.0.x being one of them).
} making grep a bg-ed process (or coproc) was
} the point of all this, after all, so that wait would recognize it.
That ought to be fixed by putting process substitutions in the job table.
} the next question would be, how efficient is the coproc?
} is it still worth it to go through all of these hoops rather than
} just write the output to a temp file? i would imagine so.
Probably depends on just how much output we're talking about. The coproc
is a pipe, so it doesn't have any filesize limit or quota on its input and
output.
On May 4, 11:43am, Bernd Eggink wrote:
} Subject: Re: exit value of intermediate program in pipe
}
} Sweth Chandramouli wrote:
} > > The last problem is that grep won't exit until it sees EOF on its stdin,
} > > but >&p dups the coproc input without actually closing it.
}
} In ksh, the normal way to kill a coproc is
}
} exec 3<&p 3<-
Do you mean 3<&- or is <- magic in ksh? (In zsh, <&- is magic but it only
works on stdin, it doesn't take a digit to the left.)
} because just killing the job doesn't close the file descriptor.
It may not in zsh either. Anyway, I'm curious about that ksh-ism, because
it closes the coproc's *output*, not it's input -- so it's assuming that
the coproc will die on a "broken pipe" signal, which isn't necessarily
true. (As my "yes" example demonstrates, closing the input won't always
work either, but presumably you don't normally coproc something that is
going to ignore its input.)
My "coproc exit" hack works because it closes the old coproc input so as
to not leak the descriptor. But it wouldn't have been incorrect for it
to leave it open, as far as documented behavior goes (which isn't far).
} In
} zsh-3.1.3, this doesn't work (a bug, IMHO), but you can kill the job
} without getting problems.
If you kill the job, you may lose some of its output. The only correct
way is to close the input and let it die in its own good time.
Can somebody out there who has ksh tell me whether
cat |&
echo >&p
causes cat to exit? That is, does redirection to the coproc make the
coproc input no longer available to any other process? In zsh, I can do
coproc cat
while true; do echo foo >&p; done &
while true; do echo bar >&p; done &
cat <&p
and get back
foo
foo
foo
bar
foo
bar
foo
bar
bar
foo
(etc. until killed)
That is, zsh will re-open the same coproc input as often as you like,
and never closes it until you start a new coproc. Does ksh do that?
} You can have more than one coprocs at a time. Just copy the fd's:
}
} coproc f
} exec 3>&p 4<&p # or whatever numbers you like
} coproc g
Right; if you do that, then my "coproc exit" trick won't stop the first
coproc, because its input has already been dup'd once and the dup is
kept open.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: exit value of intermediate program in pipe
1998-05-04 4:54 ` Sweth Chandramouli
@ 1998-05-04 9:43 ` Bernd Eggink
1998-05-04 11:42 ` Bart Schaefer
0 siblings, 1 reply; 12+ messages in thread
From: Bernd Eggink @ 1998-05-04 9:43 UTC (permalink / raw)
To: Sweth Chandramouli; +Cc: zsh-users
Sweth Chandramouli wrote:
> > The last problem is that grep won't exit until it sees EOF on its stdin,
> > but >&p dups the coproc input without actually closing it. So the grep
> > won't get EOF when blah exits. You have to shut it down some other way;
> > the only thing I've found is to start another coprocess. I don't know
> > if this is a bug, or what.
> at first, i wasn't sure if this would be a bug or not; it would
> make some conceptual sense to have a "coprocess exit" command that closed
> out a coprocess, and when i tried to find some docs on coproc, all i could
> find was the fmli coproc, which uses a similar cocreate/codestroy metaphor.
> as far as i can tell, though, zsh coproc just swallows the eof, since doing
> an
> echo "^D" >&p
> should otherwise have the same effect as "coproc exit", but doesn't. and
> _that_ is something that i _would_ consider a bug.
In ksh, the normal way to kill a coproc is
exec 3<&p 3<-
because just killing the job doesn't close the file descriptor. In
zsh-3.1.3, this doesn't work (a bug, IMHO), but you can kill the job
without getting problems.
> does this mean that you can only have one coproc open at a
> time? i could see situations where it might be useful to have more
> than one coproc open at once, rather than opening and closing the
> same two executables over and over in rapid succession.
You can have more than one coprocs at a time. Just copy the fd's:
coproc f
exec 3>&p 4<&p # or whatever numbers you like
coproc g
Now you can communicate with f and g separately:
print -u3 "to f"
read -u4 x # from f
print -p "to g"
read -p y # from g
Regards,
Bernd
--
Bernd Eggink
Regionales Rechenzentrum der Uni Hamburg
eggink@rrz.uni-hamburg.de
http://www.rrz.uni-hamburg.de/eggink/BEggink.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: exit value of intermediate program in pipe
1998-05-03 22:15 ` Sweth Chandramouli
@ 1998-05-04 1:35 ` Bart Schaefer
1998-05-04 4:54 ` Sweth Chandramouli
0 siblings, 1 reply; 12+ messages in thread
From: Bart Schaefer @ 1998-05-04 1:35 UTC (permalink / raw)
To: Sweth Chandramouli, zsh-users
On May 3, 6:15pm, Sweth Chandramouli wrote:
: Subject: Re: Re: exit value of intermediate program in pipe
:
: in ksh i would do
:
: {
: grep -v bar |&
: print -p `/bin/blah ; exitstatus=$?`
: read -p output
: echo $output
: return $exitstatus
: }
You can do exactly that same thing, except insted of
grep -v bar |&
You'd say
coproc grep -v bar
Both print -p and read -p are the same in zsh as in ksh.
Of course, you probably want
while read -p output
do print -r $output
done
as each read consumes only one line, not the entire stream.
: for zsh, would i just do
:
: {
: grep -v bar coproc |
: >&p `/bin/blah ; exitstatus=$?`
That line doesn't do what you think. What you'd want is just
/bin/blah >&p
exitstatus=$?
: <&p output ; echo $output
That's not right either. You'd probably need
cat <&p
and you'd probably have to start it before you started /bin/blah, if
blah could potentially produce more than a few kbytes of output.
: return $exitstatus
: }
The last problem is that grep won't exit until it sees EOF on its stdin,
but >&p dups the coproc input without actually closing it. So the grep
won't get EOF when blah exits. You have to shut it down some other way;
the only thing I've found is to start another coprocess. I don't know
if this is a bug, or what.
So you get
{
coproc grep -v bar
cat <&p &
/bin/blah >&p
exitstatus=$?
coproc exit # Shuts down grep by closing its input, as
# a side-effect of starting a new coproc
# which then immediately exits. Ewww.
wait # Allows cat to finish, just in case.
return $exitstatus
}
I think { /bin/blah >>(grep -v bar) } is a lot nicer, don't you?
: what zsh really needs is something like the hawksbill book from
: oreilly for ksh, that gives a lot of examples and compares it to other
: shells
There's a lot of that in the FAQ, found in Etc/FAQ in the zsh dist.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: exit value of intermediate program in pipe
1998-05-03 6:17 ` Sweth Chandramouli
@ 1998-05-03 9:30 ` Bart Schaefer
1998-05-03 22:15 ` Sweth Chandramouli
0 siblings, 1 reply; 12+ messages in thread
From: Bart Schaefer @ 1998-05-03 9:30 UTC (permalink / raw)
To: Sweth Chandramouli, zsh-users
On May 3, 2:17am, Sweth Chandramouli wrote:
} Subject: Re: Re: exit value of intermediate program in pipe
}
} isn't this what wait was designed for?
}
} foo () {
} /bin/blah >>(grep -v "foo")
} wait
} }
That doesn't work, because process substitutions [which is what >>(...)
is] and command substitutions [`...` and $(...)] are not placed in the
job table. The wait command only waits for jobs that were backgrounded
with &. (This could be considered a bug, I suppose.)
} what exactly is the syntax that >> uses to become a pipe
When the >> is immediately followed by a parenthesized command list, it
means pipe to that list. There's also >(...) which uses a FIFO.
This is in the zsh tekinfo documentation, under "Process Substitution".
For input, <<(...), <(...), and =(...) use a pipe, a FIFO, and a temp
file, respectively.
} the way you describe it looks a lot like a ksh two-way pipe
Not having used ksh much and never having seen any ksh doc, I'm not sure
what that means; but the pipe isn't two-way.
} as i mentioned in my other
} reply to this thread, i've never been able to get |& to work
That just means redirect both stdout and stderr as the pipe input. It is
a csh-ism, and not equivalent to the ksh syntax. See the FAQ. (I think
that means that you want the "coproc" builtin and <&p and >&p redirection
for setting up a "two-way pipe.")
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: exit value of intermediate program in pipe
1998-05-02 22:24 Steve Talley
1998-05-03 0:50 ` Sweth Chandramouli
1998-05-03 1:38 ` Timothy J Luoma
@ 1998-05-03 2:08 ` Bart Schaefer
1998-05-03 6:17 ` Sweth Chandramouli
2 siblings, 1 reply; 12+ messages in thread
From: Bart Schaefer @ 1998-05-03 2:08 UTC (permalink / raw)
To: Steve Talley, zsh-users
} foo () {
} /bin/blah | grep -v "foo"
} }
}
} I would like this function to exit with the exit value from the
} /bin/blah process, but it exits with the exit value from grep instead.
You can do this:
foo() {
/bin/blah >>(grep -v "foo")
}
That effectively runs grep in the background and blah in the foreground,
while still connecting them with a pipe. Then you get the exit status of
blah, but with the side effect that the function returns as soon as blah
finishes, without waiting for the grep -- which may not be what you want.
I don't think there's any other way to do this without using a temp file.
foo() {
local outfile=${TMPPREFIX}blah.out
/bin/blah > $outfile
local exitval=$?
grep -v "foo" $outfile
command rm -f $outfile
return $exitval
}
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: exit value of intermediate program in pipe
1998-05-02 22:24 Steve Talley
1998-05-03 0:50 ` Sweth Chandramouli
@ 1998-05-03 1:38 ` Timothy J Luoma
1998-05-03 2:08 ` Bart Schaefer
2 siblings, 0 replies; 12+ messages in thread
From: Timothy J Luoma @ 1998-05-03 1:38 UTC (permalink / raw)
To: Steve Talley; +Cc: zsh-users
Author: talley@boulder.Central.Sun.COM (Steve Talley)
Original-Date: Sat, 2 May 1998 16:24:40 -0600
Message-ID: <199805022224.QAA03113@ipecac.Central.Sun.COM>
> foo () {
> /bin/blah | grep -v "foo"
> }
>
> I would like this function to exit with the exit value from the
> /bin/blah process, but it exits with the exit value from grep instead.
>
> Is there any way to do this?
Do you ming a tempfile ?
foo () {
tmp=/tmp/$0.$USER.$$
/bin/blah > $tmp 2>&1
exit="$?"
grep -v foo $tmp && /bin/rm -f $tmp
exit $exit
}
You don't have to use /tmp as the tempdir if you have security concerns..
$HOME would work just as well.
TjL
ps -- if you use this function in your shell, doesn't it kill the shell ?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: exit value of intermediate program in pipe
1998-05-02 22:24 Steve Talley
@ 1998-05-03 0:50 ` Sweth Chandramouli
1998-05-03 1:38 ` Timothy J Luoma
1998-05-03 2:08 ` Bart Schaefer
2 siblings, 0 replies; 12+ messages in thread
From: Sweth Chandramouli @ 1998-05-03 0:50 UTC (permalink / raw)
To: zsh-users
On Sat, May 02, 1998 at 04:24:40PM -0600, Steve Talley wrote:
> I have a function foo:
>
> foo () {
> /bin/blah | grep -v "foo"
> }
>
> I would like this function to exit with the exit value from the
> /bin/blah process, but it exits with the exit value from grep instead.
if running /bin/blah isn't very compute-intensive, and doesn't
change its own subsequent input in any way (so that it can be run twice
consecutively with the same results), why not try
foo () {
/bin/blah > /dev/null ; exitstatus=$?
/bin/blah | grep -v "bar"
return $exitstatus
}
in theory, there should be some cleaner way to do this using
a two-way pipe, but i've never been able to get them to work correctly.
i think there are ways to export the value of a variable out of a code
block, which would also do the trick, but
{ /bin/blah ; export exitstatus=$? } | grep -v "bar" ; return $exitstatus
, which is how i thought that was done, didn't work.
-- sweth.
--
"Countin' on a remedy I've counted on before
Goin' with a cure that's never failed me
What you call the disease
I call the remedy" -- The Mighty Mighty Bosstones
^ permalink raw reply [flat|nested] 12+ messages in thread
* exit value of intermediate program in pipe
@ 1998-05-02 22:24 Steve Talley
1998-05-03 0:50 ` Sweth Chandramouli
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Steve Talley @ 1998-05-02 22:24 UTC (permalink / raw)
To: zsh-users
I have a function foo:
foo () {
/bin/blah | grep -v "foo"
}
I would like this function to exit with the exit value from the
/bin/blah process, but it exits with the exit value from grep instead.
Is there any way to do this?
Steve
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~1998-05-05 12:10 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-05-05 11:54 exit value of intermediate program in pipe Bernd Eggink
-- strict thread matches above, loose matches on Subject: below --
1998-05-02 22:24 Steve Talley
1998-05-03 0:50 ` Sweth Chandramouli
1998-05-03 1:38 ` Timothy J Luoma
1998-05-03 2:08 ` Bart Schaefer
1998-05-03 6:17 ` Sweth Chandramouli
1998-05-03 9:30 ` Bart Schaefer
1998-05-03 22:15 ` Sweth Chandramouli
1998-05-04 1:35 ` Bart Schaefer
1998-05-04 4:54 ` Sweth Chandramouli
1998-05-04 9:43 ` Bernd Eggink
1998-05-04 11:42 ` Bart Schaefer
1998-05-04 12:03 ` Bernd Eggink
1998-05-04 15:59 ` Bart Schaefer
1998-05-05 11:39 ` Bernd Eggink
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).