Hello autoconfers.
Since all the non-museum systems Autoconf strives to support should by now
have a POSIX shell somewhere [1][2], I think it would be nice if we could
finally start to move away from the need to support "classical" Bourne
shells (which, remember, do not support $(...) command substitution, $((..))
arithmetic expansion, command negation with '!', '-e' option for the 'test'
builtin, ${var#PATTERN} and ${var%PATTERN} parameter expansion, and so on;
quite a crippling for both readability and performances -- the latter
because the missing features must be emulated by spawning further processes).
As a first step, we could have autoconf offer an option that will cause the
generated configure script to punt if it's unable to find a working POSIX
shell somewhere in the system. We won't make this the default behaviour
at first, for a better backward-compatibility. If we see that the idea
works out well, the default could be switched in a future Autoconf version,
and then maybe support for non-POSIX shells could be removed altogether in
a later version (maybe a good excuse to name that Autoconf 3.0 :-).
WDYT? Is this something worth pursuing for Autoconf 2.70?
Thanks,
Stefano
-*-*-*-
*Notes*
[1] For example, Solaris, while having a ludicrously braindead /bin/sh, also
comes with a decent POSIX shell installed by default in /usr/bin/xpg4/sh.
[2] The Git project strives to be portable to all POSIX-conforming shells,
both in its testsuite and in its subcommands implemented as shell scripts,
but it doesn't support non-POSIX Bourne shells. So far it hasn't had any
problem with such requirements AFAIK, although (at least according to its
Makefile), it targets all the following systems:
GNU/Linux, GNU/kFreeBSD, Darwin, Solaris (back to SunOS 5.6), AIX, OSF1
Cygwin, MinGW, FreeBSD, OpenBSD, NetBSD, IRIX, HP-UX (11.0 and 10.20),
Interix, UnixWare and Minix.
