[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ./configure problems
From: |
Eric Sunshine |
Subject: |
Re: ./configure problems |
Date: |
Tue, 4 May 2004 23:24:11 -0400 |
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
- ./configure problems, Stremler, 2004/05/01
- Re: ./configure problems, Eric Sunshine, 2004/05/01
- Re: ./configure problems, Alexandre Duret-Lutz, 2004/05/02
- Re: ./configure problems, Eric Sunshine, 2004/05/02
- Re: ./configure problems, Alexandre Duret-Lutz, 2004/05/03
- Re: ./configure problems,
Eric Sunshine <=
- Re: ./configure problems, Paul Eggert, 2004/05/05
- Re: ./configure problems, Eric Sunshine, 2004/05/10
- Re: ./configure problems, Bob Friesenhahn, 2004/05/10
- Re: ./configure problems, Alexandre Duret-Lutz, 2004/05/11
- Re: ./configure problems, Eric Sunshine, 2004/05/11
- Re: ./configure problems, Eric Sunshine, 2004/05/20
- Re: ./configure problems, Eric Sunshine, 2004/05/05
Re: ./configure problems, Stremler, 2004/05/05