configure script for GNU sed 4.8 generated by buggy unreleased Autoconf (was re: "configure" tries to execute what seems to be a shell command)

[Zack Weinberg]

On Sat, Sep 5, 2020 at 7:51 AM Sidney Cadot <sidney@jigsaw.nl> wrote:
> When running ./configure (or even just ./configure --help), an execve()
> syscall is done to execute what seems to be a shell command.
>
> Usually the first argument to execve() is something like "/bin/sed" or
> "/usr/bin/gawk", but in this case it is:
>
> "if test ${ZSH_VERSION+y} && (emulate sh) >/dev/null 2>&1\nthen :\n
[...]

This appears to have been a bug in the unreleased version of Autoconf
that was used to generate the configure script for GNU sed version
4.8, namely 2.69.202-d78a.  The bug is mostly harmless, since there's
never going to be an actual executable with this name.  It does mean
configure's search for a shell that supports user-defined functions
doesn't work, which could mean that the configuration process fails
unnecessarily on some very old operating systems.  I'm curious how you
came to notice it.

I cannot reproduce the bug with a configure script generated by
autoconf 2.69 or by the current development trunk version of autoconf
(2.69b.68-a1e8) but I *can* reproduce it with Debian's /bin/sh and the
configure script shipped with GNU sed 4.8.  That script contains a
command looking something like

$as_echo "$as_bourne_compatible""$as_required" | as_run=a "$as_shell"

$as_echo is not set at this point, so the long strings in the
variables $as_bourne_compatible and $as_required are concatenated and
then evaluated as a single shell word which ought to be the name of an
executable; hence the `execve` call you observed.

If the configure script is regenerated with autoconf 2.69, the same
command is emitted but $as_echo *is* set at that point.  If it is
regenerated by development-trunk autoconf, this command becomes a
different construct that does not assume $as_echo is set,

as_run=a "$as_shell" -c "$as_bourne_compatible""$as_required"

The range of unreleased autoconf versions with this bug is quite
large; the bug was introduced with commit
2b59b6f8a79b8bf77e178ff4e5aa0ede433d39cf (2013-01-28) and fixed in
9894c7b5ba694820636f79ddec0c82e23af5e8e0 (2020-03-12).

I don't think there's anything more we can do in Autoconf, but I'm
cc:ing the maintainer of GNU sed to let them know that they might want
to spin a new release with a version of autoconf that doesn't have
this bug.  (N.B. I plan to put out 2.69c, i.e. the second beta for the
upcoming autoconf 2.70, early next week.)

zw