2017-05-24 13:02:56 +0000, Austin Group Bug Tracker:
[...]
> (0003745) joerg (reporter) - 2017-05-24 13:02
> http://austingroupbugs.net/view.php?id=767#c3745
> ----------------------------------------------------------------------
> It seems that we should set up a list of shell implementations that
> should be looked at when cheking for new POSIX ideas.
Moving the discussion to the mailing list as it's not relevant
to issue 767 specifically.
> First, I believe that "yash" and "posh" should not be in that list
> because these implementations are too buggy or have unexplained
> deviations. "yash" is able to run configure, but "posh" is so buggy
> that it will not run a "configure" script at all.
If your "configure" script works with "mksh" but not with
"posh", I suspect it's because that script is using non-POSIX
ksh extensions, as basically mksh is pdksh with a few fixes and
extensions added, while posh is pdksh with a few fixes and most
ksh extensions (over POSIX, not over Bourne) removed.
Note that AFAIK, posh's target is the Debian policy, not POSIX. Though
the Debian policy is for the most part a superset of POSIX (and
a few parts from Unix/XSI)
> So a useful list should have:
>
> bash
> bosh
As discussed, as of the 2017-05-16 release, posh was not POSIX
and still had many of non-conformances of the Bourne shell.
> dash
> mksh
> ksh88
> ksh93
>
> I am not sure whether we should add "zsh" to this list as zsh
> by default implements many intentional deviations to the standard.
>
> Note that I know of no way of doing zsh / POSIX related tests
> that work except for copying zsh to /tmp/sh and then test with
> /tmp/sh, as I could not find a better way to make zsh compliant
> enough to be able to run a "configure" script.
[...]
Aside from the fact that zsh is in my opinion the Bourne-like
shell which has made some of the best designs decisions and
should be at least considered as a source of inspiration for the
future of the specification (again, my opinion only), zsh is
relevant in that it has a "sh" mode that is typically used to
interpret POSIX code.
emulate sh # to emulate sh
emulate -L sh # to emulate sh in the local scope only
emulate sh -c 'some code' # to evaluate the code as "sh"
# (and also stick the sh emulation to
# the functions defined in that code)
That "sh" emulation used to target the SysV shell, but has
gradually switched to POSIX over the last decades.
zsh enters the "sh" emulation mode when invoked as "sh", but I'm
not sure I would use zsh for the system's sh (note however that
when it comes to multibyte processing, it's more compliant than
shells like dash, posh or mksh).
mksh, bash and yash at least have a "posix" option to enforce a
more compliant mode (at least bash enables it when invoked as
"sh"). See also the xpg_echo option in bash which you also need
to have a compliant echo.
So in that regard, the main difference between bash and zsh is
the amount of different between the posix mode and the default
mode.
--
Stephane
