Dan Nicolaescu <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
> > Dan Nicolaescu <[EMAIL PROTECTED]> wrote:
> > > I have been using this alias: lt = 'ls -lt | head'
> > ...
> > > ls: write error: Broken pipe
> > >
> > > Is there any reason for this error to be printed?
> >
> > Hi Dan,
> >
> > You should see it only if you have changed the default signal
> > handling to ignore SIGPIPE, and then only some of the time.
> > When it's possible to see it, kernel buffering and the size of your
> > environment also determine how much can be written before the
> > signal is sent.
>
> Hmm, that probably explains the behavior I am seeing: in the beginning
> no error, but after executing a few commands (i.e. the history size
> grows)
>
> This is with tcsh, and AFAIK tcsh does not have a way to tell it
I'm sure you've already heard it, but I have to say it:
You shouldn't use csh-based shells.
If you ask anyone or google, you'll find many good reasons.
Lack of a decent signal-handling mechanism is one of them.
> whether to catch SIGPIPE or not. Maybe something has changed in tcsh
> to make it catch SIGPIPE...
How do you start tcsh?
If you start from another shell that *does* ignore SIGPIPE,
that would explain it.
FWIW, I've just tested with tcsh-6.14.00 on debian unstable and
tcsh-6.15-1.fc8 on fedora rawhide, and neither does what yours does
when run interactively:
$ tcsh
tcsh$ seq 99999|head -1
1
tcsh$
But when run via -c, tcsh's exit code indicates the SIGPIPE:
(it's my prompt-handling code that displays the "[Exit 141 (PIPE)]")
$ tcsh -c 'seq 99999|head -1'
1
[Exit 141 (PIPE)]
If you ever get in the mood to switch, consider zsh.
_______________________________________________
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
