autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ./configure problems


From: Eric Sunshine
Subject: Re: ./configure problems
Date: Mon, 10 May 2004 18:50:31 -0400

On Wed, 05 May 2004 10:32:04 -0700, Paul Eggert wrote:
> Eric Sunshine <address@hidden> writes:
> > 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(?).
> I can see where it might matter, e.g., if some sysadmin has done
> something like "ln -s /usr/local/bin/tcsh /bin/sh".
> (Yes, some people have actually done that sort of thing....)

This would not generally be a problem. For this case, it would be testing a  
shell named "/bin/sh", the test would fail (because it's not actually  
Bourne-compatible), thus it would not consider "/bin/sh" a usable shell. The  
case which Alexandre described was different in that it was testing a shell  
named "/bin/tcsh" (or /usr/bin/tcsh or such), and the test appeared to  
succeed on account of the 'exec /bin/zsh' at the end of .tcshrc. Thus, it was  
fooled into thinking the shell named /bin/tcsh was usable, despite the fact  
that it was not.

> It sounds like an easy patch, and if so could you please submit it?

I started working on this, but ran into some issues.

On Mon, 03 May 2004 08:44:46 +0200, Alexandre Duret-Lutz wrote:
> 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.

I am unable to reproduce the second claim where you say that "$as_shell  
./script" invokes the shell in such a way that it does not read your .tcshrc.  
In my tests, .tcshrc was read for all cases, regardless of how the shell was  
invoked. In fact, the tcsh manual page agrees with my tests; it says that  
.tcshrc is always read (unlike .login, which is read only for a login shell).

> 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.

What is worse, by having 'exec zsh' at the bottom of your .tcshrc, none of  
the command-line arguments passed to tcsh get passed to zsh. Thus, if I  
invoke "tcsh foo bar moo", zsh (as exec'd by .tcshrc) sees only an empty  
argument list.

I would think that you really want to be using .login for your 'exec zsh'  
rather than .tcshrc. This seems to be the type of user error (code in .tcshrc  
which actually belongs in .login) which we can not easily deal with in an  
automated fashion in Autoconf's startup code. Furthermore, even if you did  
really intend to insert 'exec zsh' into .tcshrc, there doesn't seem to be any  
good way to forward tcsh's command-line arguments to zsh.

-- ES




reply via email to

[Prev in Thread] Current Thread [Next in Thread]