On 2020-06-07 at 16:55:54, Bart Schaefer wrote: > On Fri, Jun 5, 2020 at 1:42 PM brian m. carlson > wrote: > > > > I will tell you that as a practical matter, nobody writing code for sh > > expects the last command not to be run in a subshell and consequently > > lots of code is practically broken in this case with zsh as /bin/sh. > > I believe you, but would be curious to see an example. I'll demonstrate an example from the Git testsuite (t1300), which is necessarily incomplete, and whose behavior baffles me a bit. echo "[broken" | test_must_fail git config --list --file - >output 2>&1 && test_i18ngrep "bad config line 1 in standard input" output test_must_fail checks for a nonzero, non-SIGSEGV exit code, and test_i18ngrep is a glorified grep operation which always succeeds when LC_ALL=C doesn't work. There is also a lot of FD redirection going on under the hood. This operation fails, interestingly enough, because grep complains that the output is also the input; that is, the redirection of stdout on the previous line applies to the grep as well. I'm unable to reproduce this with a simpler example, but putting it in a subshell does work. AT&T ksh does not have this behavior, and so this may be a legitimate bug in zsh which my patch happens to fix. The other case (t0410) in the Git testsuite is more straightforward; we have this function: pack_as_from_promisor () { HASH=$(git -C repo pack-objects .git/objects/pack/pack) && >repo/.git/objects/pack/pack-$HASH.promisor && echo $HASH } and that function is then called on the right end of a pipe. The caller was not expecting that HASH would be overwritten, and since until recently the Git testsuite did not allow "local" and this test has not been updated, the test gets the wrong value. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204