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
Attachment:
signature.asc
Description: PGP signature
