Re: subtle `echo' bug

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jun 15, 11:48am, Alexey Tourbin wrote:
> Subject: Re: subtle `echo' bug
>
> On Wed, Jun 15, 2005 at 12:28:44AM +0000, Bart Schaefer wrote:
> > In short, if you write nonsense code, you get nonsense results.  Don't
> > try to feed input to a command that doesn't want it.
> 
> It was quite a real command!

I don't doubt that.  The point is that " ... | echo" is nonsense, no
matter what good reason you may have had for attempting it, because
that's writing on the standard input of a command that does not read
from standard input.

In other words, even with " ... | /bin/echo" in your example here:

>       ... {
> 	echo "$v1 has problems with $v2..." |fmt; grep -w $v2 list; } |
> 	/bin/echo ...

If "grep -w $v2 list" generates a sufficient volume of output, the pipe
on /bin/echo's stdin can fill up and the command may fail.  It's not a
zsh problem, it's a fundamental problem with the nature of unix pipes
and the way you're using them.

Zsh happens to make the problem show up sooner because the first echo
gets a write error when the second echo fails to read; but that's not
a bug, unless echo is somehow required never to fail on write error.

> I used "echo" as a comment to find out and check twice the commands that
> were going to be executed.

The right thing would be something like this, which reads and throws
away its input:

    { ... } | { cat > /dev/null; echo /path/to/my/script ... }

You could make a function:

    notreally() {
       [[ -t 0 ]] || cat > /dev/null
       print -R "$@"
    }

And then

    ... | notreally /path/to/my/script ...

Or, better still, since your script is parsing command line options,
add an option to it that tells it to run without doing its destructive
thing, so that you don't have to wrap it in another command to test it.

    ... | /path/to/my/script --notreally --opt...