On Sat, Sep 5, 2020 at 7:51 AM Sidney Cadot <sid...@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
