Stephane Chazelas <stephane.chaze...@gmail.com> wrote:
> 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.
This is not true...
A configure script (if done correctly) is a script with _very_
pessimistic assumptions on portability. Given that "posh" completely fails
here, makes it unusable for every day work.
> 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)
I have no idea what "posh" targets, but given that:
posh
$ exit
posh: exit: bad number
and that a similar error is created with "break", I cannot take it for serious.
also:
CONFIG_SHELL=/tmp/posh /tmp/posh ./configure
./configure:728: bad signal rm -fr conftest* confdefs* core core.* *.core
$ac_clean_files; exit 1, not setting trap
creating cache ./config.cache
./configure:872: break: break: bad number
The line in question is:
trap 'rm -fr conftest* confdefs* core core.* *.core $ac_clean_files; exit 1' 1
2 15
> > 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.
"posh" has a 2017-05-16 release?
> > 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).
Multi byte support is really a problem.
dash and posh do not implement multi byte support at all and thus
may only certified as system shell for an embedded UNIX version.
Moreover, dash is a _very_ slow shell. If it did ever implement
multi byte support it would be slower than bash.
mksh needs "-o utf8-mode -o posix" to work as expected.
Back to zsh:
If there is no way to modify this command line:
CONFIG_SHELL=/usr/bin/zsh /usr/bin/zsh ./configure
in a way that allows to run the configure script, this is a bad
state for the current usability of zsh. I currently need to do the
following:
cp /usr/bin/zsh /tmp
CONFIG_SHELL=/tmp/sh /tmp/sh ./configure
> 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.
There are a few features where the "Bourne Shell" would cause problems
with existing Bourne Shell scripts if it was by default 100% POSIX.
For this reason it implements set -o posix that is auto-activated if it was
installed as /usr/xpg4/bin/sh (note that a symlink will not work here).
If you like to use the Bourne Shell as Linux default shell, compile it with:
-DDO_POSIX_SH to enable -o posix whenever argv[0] ends in /sh
-DPOSIX_BOSH_PATH="other-path" to enable something different
than /usr/xpg4/bin/sh
>From the man page for -o posix:
This currently disallows to use
``^'' as the pipe symbol, switches
off support for test -t without a
parameter and sets the default for
directory operations to -L.
POSIX mode is enabled by default if
the executable path of the shell
equals a compiled in value, e.g.
/usr/xpg4/bin/sh.
> So in that regard, the main difference between bash and zsh is
> the amount of different between the posix mode and the default
> mode.
I believe the main difference is that bash intends to be POSIX compatible.
Jörg
--
EMail:jo...@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
