[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Automake 1.15.1 released

From: Michael Felt
Subject: Re: GNU Automake 1.15.1 released
Date: Wed, 26 Jul 2017 14:39:51 +0200

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!

    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; }
 print 77
 print not 77

The result is "77" for ksh93 (and "not 77" for ksh)

On Tue, Jun 20, 2017 at 7:31 PM, Warren Young <address@hidden> wrote:
> On Jun 19, 2017, at 2:50 PM, Mathieu Lirzin <address@hidden> 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 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]