one example of this behaviour that i use
all the time is:
tar t foo.tar | sed 10q
just to get some idea of the contents of foo.tar.
often the tar file is huge, and i won't get a command
prompt back until all the elements of the pipeline
have completed - whereas i want it to finish quickly.
you don't really want to get write error printed from every
process in a pipe line such as
slowly-compute-big-file | dosomemore | andyetmore | sed -n
'/something/;p;q'
or even
slowly-compute-big-file | badusageofsomething
where the latter prints a usage message and quits.
you want
pipe would return -1 (and set a error condition) and the
applications were paying attention (and I'm pretty sure all
applications on Plan 9 would do a reasonable thing when
presented with -1 from a write).
they only notice when the write occurs. suppose that takes
several minutes of computation.
On Mon, 2009-07-20 at 01:21 -0400, erik quanstrom wrote:
one last kick of a dead horse: see that's exactly what I'm
talking about -- all these exceptions and for what? I'm
pretty sure if we change the devpipe today not to send
a note nobody would even notice...
since you're confident
On Mon, 2009-07-20 at 10:53 +0100, Charles Forsyth wrote:
pipe would return -1 (and set a error condition) and the
applications were paying attention (and I'm pretty sure all
applications on Plan 9 would do a reasonable thing when
presented with -1 from a write).
they only notice when the
On Mon, 2009-07-20 at 10:52 +0100, Charles Forsyth wrote:
you don't really want to get write error printed from every
process in a pipe line such as
As much as I thought that could be an issue, I could NOT actually
make many of the commands I tried produce this message on a
modified 9vx:
you're right. i wasn't thinking correctly.---BeginMessage---
On Mon, 2009-07-20 at 10:53 +0100, Charles Forsyth wrote:
pipe would return -1 (and set a error condition) and the
applications were paying attention (and I'm pretty sure all
applications on Plan 9 would do a reasonable thing when
i did some looking through the plan 9 source.
(it's great to have it all in one place.)
all of this group, to a quick scan, should work
if the note is removed. many can lose their
note handlers, because the the pipe signal is
the only there to catch writes on closed pipes.
grep 'closed pipe'
The programs that know about the signal are
not the programs that need to be worried about.
I'm much more worried about making sure that
commands like
grep pattern /n/dump/slow/slow/sys/log/mail | sed 5q
stop as early as possible. The note is nice
precisely because it doesn't involve editing
On Mon Jul 20 22:05:50 EDT 2009, r...@swtch.com wrote:
The programs that know about the signal are
not the programs that need to be worried about.
I'm much more worried about making sure that
commands like
grep pattern /n/dump/slow/slow/sys/log/mail | sed 5q
stop as early as possible.
perhaps i've been asleep at the swtch, but i don't recall seing writes
on closed channels terminate programs with a note.
sys: write on closed pipe
mainly to kill off a pipeline when the thing at the end has finished.
i think that might be the only instance where a note is used.
On Jul 18, 2009, at 6:06 PM, erik quanstrom wrote:
On Sat Jul 18 14:41:02 EDT 2009, r...@sun.com wrote:
In the mom, why sky is blue department, here's a silly question:
is there any good reason that read(2) on a hangup channel returns
an error, while write(2) on a hangup channel terminates an
Observe:
also observe (as ron noted) this happens mostly on
pipes. this would tend to cause pipes to shutdown
from right to left.
; 8c -FVTw roman.c 8l -o roman roman.8
; {roman | dd /dev/null} sleep 7; slay dd|rc
write good
write good
; note: sys: write on closed pipe pc=0x270a
write:
On Jul 19, 2009, at 2:30 AM, Charles Forsyth wrote:
perhaps i've been asleep at the swtch, but i don't recall seing
writes
on closed channels terminate programs with a note.
sys: write on closed pipe
mainly to kill off a pipeline when the thing at the end has finished.
i think that might be
On Sun, Jul 19, 2009 at 10:30:41AM +0100, Charles Forsyth wrote:
perhaps i've been asleep at the swtch, but i don't recall seing writes
on closed channels terminate programs with a note.
sys: write on closed pipe
mainly to kill off a pipeline when the thing at the end has finished.
i
On Jul 19, 2009, at 2:55 PM, Charles Forsyth wrote:
not for network connections?
i think pipe is the only case, and even that is suppressed
for pipes that carry 9p, after mounting.
one last kick of a dead horse: see that's exactly what I'm
talking about -- all these exceptions and for what?
one last kick of a dead horse: see that's exactly what I'm
talking about -- all these exceptions and for what? I'm
pretty sure if we change the devpipe today not to send
a note nobody would even notice...
since you're confident that this exception is spurious,
why don't you remove it from
In the mom, why sky is blue department, here's a silly question:
is there any good reason that read(2) on a hangup channel returns
an error, while write(2) on a hangup channel terminates an application
(by generating a note, of course, which can be ignored, but still)?
Thanks,
Roman.
P.S. And
On Sat Jul 18 14:41:02 EDT 2009, r...@sun.com wrote:
In the mom, why sky is blue department, here's a silly question:
is there any good reason that read(2) on a hangup channel returns
an error, while write(2) on a hangup channel terminates an application
(by generating a note, of course, which
19 matches
Mail list logo
