On 2020-06-07 at 16:55:54, Bart Schaefer wrote:
> On Fri, Jun 5, 2020 at 1:42 PM brian m. carlson
> <sandals@xxxxxxxxxxxxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature