Re: [Fixed Hardwrap][BUG] Pipe fails even when using ' || true '

[Bart Schaefer <schaefer@brasslantern.com>]

On Fri, Mar 26, 2021 at 6:09 AM Rudi C <rudiwillalwaysloveyou@gmail.com> wrote:
>
> This pipe unexpectedly fails:
>
> ```
> $ setopt pipefail
> $ { print -nr -- "x" || true } | eval 'print -rn -- "${(q+@)brish_stdin}"' ; echo $'\n'Returned $?:"${(j.|.)pipestatus[@]}"
> ''
> Returned 141:141|0
> ```

Exit status 141 indicates that the entire { ... } construct was killed
by SIGPIPE,which is occurring because there's nothing in the "eval" on
the right side to read the output from "print".

Whether this happens depends on order of events (does the right side
of the pipe exit before the left side finishes printing) which can in
turn depend on OS-level process scheduling algorithms over which zsh
has little or no control; or because of pipe buffering, which is also
an OS thing, although with only one character sent on the pipe that is
unlikely to be the cause in this case.

> The behavior is nondeterministic on macOS, and it actually doesn't usually fail at all!

See "order of events".  Process scheduling may depend on how many
actual cores are in the CPU, for example, determining whether the
pipeline executes in true parallel fashion or via time-slicing.

> BTW, there seems to be another weird thing going on; Adding two spaces before `echo` breaks the whole loop both on Linux and macOS:

If you're copy-pasting from an edit in browser gmail, for example, it
has a tendency to insert non-breaking spaces whenever there is more
than one consecutive space, which the shell interprets as
non-whitespace and attempts to execute as commands.  Annoys the hell
out of me whenever I forget that it happens.