[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ./configure problems
Re: ./configure problems
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
> 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
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.
Re: ./configure problems, Stremler, 2004/05/05
- ./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, 2004/05/04
- Re: ./configure problems, Paul Eggert, 2004/05/05
- Re: ./configure problems,
Eric Sunshine <=
- 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