FYI: On AIX I tried using export SHELL=/usr/bin/ksh93 and also running from /usr/bin/ksh93
ksh93 was never tested. Continued to complain that /usr/bin/ksh is not POSIX (enough) However, the test done in ./configure (somewhat simplified here) will pass if ksh93 is used as the shell! am_sh=/usr/bin/ksh93 if { $am_sh -c "$am_bourne_compatible (set -x; P=1 true 2>&3) 3>&1 2>/dev/null | grep P=1 fail=0 && foo() { trap 'fail=1' 0; } && foo && test \$fail = 0 test \$? -eq 0 || exit 1 # Use 77 to indicate success (rather than 0), in case some shell # acts like Solaris 10's /bin/sh, exiting successfully on some # syntax errors. exit 77" 2>&1; test $? -eq 77; } then print 77 else print not 77 fi The result is "77" for ksh93 (and "not 77" for ksh) On Tue, Jun 20, 2017 at 7:31 PM, Warren Young <war...@etr-usa.com> wrote: > On Jun 19, 2017, at 2:50 PM, Mathieu Lirzin <m...@gnu.org> wrote: >> >> - Automake-provided scripts and makefile recipes might (finally!) >> start assuming a POSIX shell in Automake 2.0. There still is no >> certainty about this though: we'd first like to wait and see >> whether future Autoconf versions will be enhanced to guarantee >> that such a shell is always found and provided by the checks in >> ./configure. > > Please clarify: does this apply to the shell script code written in *.m4 > files included in the output configure script or to shell script code written > in the user’s configure.ac file? > > Currently, it’s the end user’s look-out if they do this. What I’m suggesting > is that it is possible for Autoconf to bend over backwards to ensure that the > generated configure script runs under a local POSIX shell, if available, > thereby making possible use of POSIX shell features in end-user macros and > such even on systems where /bin/sh is not a POSIX shell. > > As I understand it, the main difficulty here is that the generated configure > script can’t start with anything other than #!/bin/sh for portability. My > suggestion is that one of the first things the generated code do is test > whether it is running under a POSIX shell, and if not, try to find one and > re-exec itself under that shell instead. > > It’s generally possible to find a POSIX-compatible shell somewhere on the > system these days if you only look hard enough: /usr/xpg4/bin/sh on old > Solaris, /bin/bash on Linuxes where /bin/sh is pre-POSIX, /usr/bin/ksh on > some SVR4 systems, etc. > > Even the shells built into Busybox are fairly POSIX-compliant these days.