>>> "Eric" == Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes: [...] Eric> I can submit a patch to autoconf-patches to make Eric> Autoconf's shell selection more backward-compatible with Eric> earlier versions of Autoconf, however this raises another Eric> issue. My interpretation of this thread is that Eric> Autoconf's new shell selection behavior is exposing a Eric> latent problem with Automake; specifically, Eric> Automake-generated makefiles do not deal with zsh in a Eric> robust fashion. Even after patching Autoconf, it will Eric> still be possible for zsh to be the chosen shell (it just Eric> won't be as likely), so this same problem can continue to Eric> affect Automake. Furthermore, it does not really seem Eric> like Autoconf's responsibility to work around a Eric> shortcoming in Automake. After all, Autoconf has long Eric> considered zsh an acceptable shell (otherwise, those zsh Eric> work-arounds would not be present in Autoconf), so one Eric> might expect Automake to also consider zsh a usable shell Eric> (by employing the same zsh goop, for instance). This discussion rejoins http://sources.redhat.com/ml/bug-automake/2004/msg00096.html A suggestion was to always use `SHELL = /bin/sh' in Makefiles. I simply don't know how correct this is, because that's how it was in the past before Chris Provenzano changed it to what it is now. The reason for that change seems to have been lost. Because Chris had a cygnus email address it could be a cygwin singularity? Maybe it's for systems that do not have /bin/sh? In automake Makefiles, most auxiliary scripts like depcomp, missing, etc. are run as an argument of $(SHELL). A few are run directly (e.g., install-sh), go figure why. Since all of them are executable, start with `#!/bin/sh', and require only basic shell features, I wonder why we bother running them we $(SHELL). Obviously when $(SHELL) is Zsh most of these scripts will break with unsplit variable symptoms. Unless we equip these scripts (and many Makefile rules) with the _AS_BOURNE_COMPATIBLE code. Regarding the aforementioned thread, I'm not really fond of the proposal to introduce a MAKE_SHELL variable and use SHELL = @MAKE_SHELL@ because in order to access the CONFIG_SHELL variable set at configure time we would have to use CONFIG_SHELL = @SHELL@ creating a spaghetti plate of variables definitions. If two variables are needed, it would seems neater to use SHELL for what it was initially introduced: a substitution for the Makefile's SHELL, and AC_SUBST CONFIG_SHELL on its own. SHELL = @SHELL@ CONFIG_SHELL = @CONFIG_SHELL@ This of course assumes we know how to compute @SHELL@, which I don't :) If I had to vote for a definition, I'd say it would be useful that @SHELL@ be the most POSIX compliant shell that does not require any configuration code (such as _AS_BOURNE_COMPATIBLE) to work. CONFIG_SHELL would allow shell that require such extra code. Note that the above definition of SHELL would be useful to configure itself. For instance it currently runs things like ac_config_guess="$SHELL $ac_aux_dir/config.guess" ac_config_sub="$SHELL $ac_aux_dir/config.sub" ac_configure="$SHELL $ac_aux_dir/configure" # This should be Cygnus configure. and I doubt these will enjoy zsh. -- Alexandre Duret-Lutz
