On Mon, 03 May 2004 08:44:46 +0200, Alexandre Duret-Lutz wrote: > >>> "Eric" == Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes: > >> CVS Autoconf selects tcsh as CONFIG_SHELL if > >> SHELL=/bin/tcsh. > >> http://mail.gnu.org/archive/html/bug-autoconf/2004-04/msg00072.html > Eric> The patch which I submitted to autoconf-patches on > Eric> 2004-04-19 will resolve this issue. > http://mail.gnu.org/archive/html/autoconf-patches/2004-04/msg00019.html > Hmm, it seems to me this will just hide this problem, not really > cure it. Am I mistaken? No, I wouldn't say that it hides the problem. If the tests have gotten this far (to the point of considering $SHELL as a candidate), then the situation is already dire. It means that the shell selection code was unable to find a suitable shell in any of the normal locations (including $PATH) under any of the normal names. The search has exhausted all normal means of locating an agreeable shell, so it might as well try $SHELL as an absolete last resort. After all, $SHELL _might_ just reference a usable shell. If it does, great, disaster averted. If it does not, well, then the dire situation is still dire. > It appears the problem is that the shell function test is run as > $as_shell 2> /dev/null <<\_ASEOF > shell code > _ASEOF > instead of > $as_shell ./shell_script 2>/dev/null > The former starts an interactive shell while the second does not. > As I've said in my report, my setup is so that the configuration > file for an interactive shell ends with `exec zsh'. Hence when you > call `tcsh <<EOF ... EOF' you are effectively running zsh and the > test passes. However, when you later run `tcsh ./configure', you > are running plain tcsh and that fails. Indeed. I can reproduce this. Testing $SHELL as a last resort seems like a reasonable idea (since all other attempts have failed), though this is obviously a case where it is problematic. On the other hand, this case is almost pathalogical, except that I can see it arising in the real world. (For instance, if the sysadmin of the Solaris box assigned tcsh as your shell but you prefer zsh, then I can understand why you would have 'exec zsh' at the end of your .tcshrc.) Considering that the patch is now in place to only attempt $SHELL as a very last resort (rather than as the second candidate), the question is: should we spend time trying to address this near pathalogical case? I suppose it would require only a fairly minor change to _AS_RUN() to have it load the shell code from a file rather than standard input. I could submit a patch if it seems worthwhile(?). (Unfortunatly, I do not seem to be receiving email from bugs-autoconf despite the fact that I am subscribed, else I would likely have responded to your original email.) -- ES
