Re: ls: write error: Broken pipe

[Jim Meyering]

Dan Nicolaescu <address@hidden> wrote:
> Jim Meyering <address@hidden> writes:
>
>   > Dan Nicolaescu <address@hidden> 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.