ksh93 does not meet POSIX shell criteria required for running the GNU Automake test suite

[atheik]

The test suite is not needed for building GNU Automake, but meeting these criteria for a POSIX shell could be relevant for ksh93:
https://github.com/autotools-mirror/automake/blob/v1.16.5/configure.ac#L230-L328

This test fails first and disqualifies ksh93 as "a sturdy POSIX shell":
https://github.com/autotools-mirror/automake/blob/v1.16.5/configure.ac#L314-L320

Support for aliases named like shell builtins:

cat <<'EOF' >conftest-alias.sh
alias false=echo
false && test "$(false 97)" = 97
EOF
. ./conftest-alias.sh
echo $?

If that test is skipped, $am_score is 9, which is "barely acceptable", due to the following test:
https://github.com/autotools-mirror/automake/blob/v1.16.5/configure.ac#L301-L304

Shell corrupts stderr with "set -x":

(set -x; P=1 true 2>&3) 3>&1 2>/dev/null | grep P=1
echo $?
# non-zero is a pass

Commit 2940b3f was the oldest version of ksh93 I tried.

If you would like, you can reproduce this in Debian Live under x86_64 QEMU:

curl -LO https://cdimage.debian.org/cdimage/release/11.2.0-live/amd64/iso-hybrid/debian-live-11.2.0-amd64-standard.iso
qemu-system-x86_64 -cpu host -accel kvm -m 1024 -drive file=debian-live-11.2.0-amd64-standard.iso,media=cdrom

Run the following in Debian Live:

sudo -i

apt-get update
apt-get install autoconf

curl -L https://codeload.github.com/ksh93/ksh/tar.gz/a833053 -o ksh-a833053.tar.gz
tar xf ksh-a833053.tar.gz
cd ksh-a833053
bin/package make
install -vm 755 arch/linux.i386-64/bin/ksh /bin/sh

exec sh -l
rm -v /bin/bash /bin/dash
# remove other shells so automake doesn't pick them up

curl -LO https://ftp.gnu.org/gnu/automake/automake-1.16.5.tar.xz
tar xf automake-1.16.5.tar.xz
cd automake-1.16.5
./configure
# passing AM_TEST_RUNNER_SHELL skips all tests

sed -i~ 's/alias false=echo/return 0; &/' configure.ac
autoreconf -vif
# first failing test is now skipped

./configure
sed '/corrupts/,/acceptable/!d' config.log

At least bash, zsh, dash, and pdksh derivatives pass these tests.
If this is considered a bug, I would happily test any suggested patches.

[JohnoKing]

The alias failure is a consequence of how ksh parses files with the . command. It's documented in the caveats section of the man page, at L9110-L9118:

The built-in command . file reads the whole file before any commands are executed. Therefore, alias and unalias commands in the file will not apply to any commands defined in the file.

Running the alias reproducer directly works as expected, while running it with . doesn't work (as documented):

$ cat /tmp/alias
alias false=echo
false >/dev/null && test "$(false 97)" = 97
echo $?
$ ksh93 /tmp/alias
0
$ ksh93 -c '. /tmp/alias'
1
$ ksh88 -c '. /tmp/alias'
1

This is deeply embedded parser behavior that has been present since the release of ksh88. Changing it would likely require implementing a parser hack or a rewrite of the parser.

[atheik]

@JohnoKing Sorry, I completely missed that the alias failure was documented. Now I know.

[McDutchie]

I cannot find anything in the POSIX standard about line-by-line vs. entire-file parsing. I may have to ask clarification from the Austin Group to see if ksh needs to change to be compliant.

Shell corrupts stderr with "set -x":

(set -x; P=1 true 2>&3) 3>&1 2>/dev/null | grep P=1
echo $?
# non-zero is a pass

This failure is because the trace of P=1 gets redirected but the trace of true does not. In other words, first it traces the command, then it performs the 2>&3 redirection, then it traces and executes the assignment, and then it executes the command.

Again, I'm not sure if this is a POSIX compliance issue or a legit implementation difference.

[hvdijk]

On the alias front: https://www.austingroupbugs.net/view.php?id=953#c4214 makes changes to the way aliases are specified and allows either behaviour.

For the dot command:

The shell shall tokenize (see [xref to XCU 2.3 Token Recognition]) the contents of the file, parse the tokens (see [xref to XCU 2.10 Shell Grammar]), and execute the resulting commands in the current environment. It is unspecified whether the commands are parsed and executed as a program (as for a shell script) or are parsed as a single compound_list that is executed after the entire file has been parsed.

For the rationale:

Some, but not all, shell implementations do not process changes to alias definitions until the current compound_list (see [xref to XCU 2.10 shell grammar]) has completed. In these shells, alias changes do not take effect until the end of the dot script, eval command, function invocation, if statement, case statement, for statement, while statement, or until statement containing the alias change.

Note that testing whether aliases that share names with shell builtins is possible inside dot scripts even in ksh, so long as the dot scripts use eval to force a delayed parse:

cat <<'EOF' >conftest-alias.sh
alias false=echo
eval 'false && test "$(false 97)" = 97'
EOF
. ./conftest-alias.sh
echo $?