Re: ./configure problems

[Eric Sunshine]

On Mon, 03 May 2004 08:44:46 +0200, Alexandre Duret-Lutz wrote:
> >>> "Eric" == Eric Sunshine <address@hidden> 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