On 2020-03-10 at 11:00:08, SZEDER Gábor wrote:
> Note, however, that 'ksh' is not utterly wrong in doing so, because
> POSIX does allow this behavior: POSIX 2.12 Shell Execution Environment,
> the last paragraph of the section:
> 
>   "each command of a multi-command pipeline is in a subshell
>    environment; as an extension, however, any or all commands in a
>    pipeline may be executed in the current environment."
> 
>    https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_12
> 
> So apparently 'ksh' implements this extension.

In my experience, trying to fix this is not productive in our test
suite.  zsh does the same thing and many of our tests fail with it for
that reason.  In the zsh case, I sent a patch to make it not do that
when emulating sh.  It got lost on their list, but I'll resend it.

There are many, many other pieces of software that are broken in such a
case, such that trying to use zsh (or any other shell that does this) as
/bin/sh (or a POSIX sh) will result in widespread breakage.  My goal in
fixing zsh is that it's a candidate for /bin/sh in macOS Catalina, and
I'd like to avoid users seeing breakage if they run in that
configuration.

My reading of the allowance for this as an extension is that zsh and ksh
can do this when invoked as zsh or ksh, but they cannot when invoked as
sh, because in that mode they are supposed to strictly conform to POSIX.
POSIX states the following:

  Non-standard extensions, when used, may change the behavior of
  utilities, functions, or facilities defined by POSIX.1-2017. The
  conformance document shall define an environment in which an
  application can be run with the behavior specified by POSIX.1-2017.

> The trivial fix would be to mark $HASH as 'local' in both helper
> functions, but this would not help 'ksh', of course, as it doesn't
> support 'local'.  However, since we use more and more 'local's in our
> testsuite, 'ksh' might be considered a lost cause anyway.

If this is the AT&T ksh, then yeah, it's a lost cause.  It's possible to
emulate local with typeset, but that only works in ksh-style functions,
not POSIX-style functions.  It also has the issue we were discussing
above.

pdksh and mksh both do the right thing with local and the last item in a
pipeline, and both are suitable for a POSIX (or Debian) /bin/sh.  I
believe OpenBSD's ksh is also fine, since it is also used as /bin/sh
there and it does support local.

I should point out that Debian has a reasonably restricted set of
requirements[0] on /bin/sh that allow a wide variety of shells to be
used, and which we may want to consider:

* /bin/sh must implement the POSIX.1-2017 shell command language.
* echo -n, if implemented as shell built-in, must not generate a
  newline.
* test must support -o and -a.
* local to create a scoped variable must be supported, including
  multiple variables and included assignments.
* kill -N where N is an integer must be supported with certain signal
  numbers.
* trap must work with certain numeric signals.

The latter two are already required by the XSI extension to POSIX.  I
personally don't see the utility in the second or third, and the first
is supported in almost every modern shell anyway (possibly with the
exception of command -v).

Of course, ksh is not included in the set of supported shells for the
two reasons outlined above.

[0] https://www.debian.org/doc/debian-policy/ch-files.html#scripts
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204