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