Re: ./configure problems

[Alexandre Duret-Lutz]

>>> "Eric" == Eric Sunshine <address@hidden> writes:

[...]

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

 Eric> I am unable to reproduce the second claim where you say
 Eric> that "$as_shell ./script" invokes the shell in such a way
 Eric> that it does not read your .tcshrc.

I'm not claiming the shell does not read .tcshrc, I'm saying it
is not interactive.  You can check whether $prompt is defined to
tell the difference, for instance.  The few .tcshrc I've seen so
far do that sort of check to disable settings (such as aliases)
that must not be active in scripts.


# Settings common to interactive and non-interactive shells
...
if ($?prompt == 0) exit
# Settings for interactive shells
...
(zsh --version) >&/dev/null && exec zsh
(/bin/zsh --version) >&/dev/null && exec /bin/zsh
(/usr/bin/zsh --version) >&/dev/null && exec /usr/bin/zsh

[...]

 Eric> What is worse, by having 'exec zsh' at the bottom of your
 Eric> .tcshrc, none of the command-line arguments passed to
 Eric> tcsh get passed to zsh. 

If there are arguments, the shell is not interactive, so zsh
should not be executed.

 Eric> I would think that you really want to be using .login for
 Eric> your 'exec zsh' rather than .tcshrc. 

.login is another thing.  When rxvt or xterm starts a shell, it
is not always login shell (depending on the options).  However
it is interactive.

 Eric> Furthermore, even if you did really intend to insert
 Eric> 'exec zsh' into .tcshrc, there doesn't seem to be any
 Eric> good way to forward tcsh's command-line arguments to zsh.

Just to be clear, when `tcsh foo' is executed, it's because foo
is a tcsh script.  It would be a user-error if Zsh was run.
-- 
Alexandre Duret-Lutz