>>> "Eric" == Eric Sunshine <sunshine@xxxxxxxxxxxxxx> 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
