Perhaps I'm missing something, but couldn't you set up your .cshrc
such that it determines whether this is an interactive shell or not, and
behave accordingly? A help article (assuming you've got a such a local thing)
on the matter should benefit those who go searching for a bug fix to ssh,
if you add "ssh" as a lookup keyword.
Something like:
if ( $?prompt ) then
# Do interactive shell stuff here
endif
# Do non-interactive shell stuff here
Re:
> From: Sami Lehtinen <[EMAIL PROTECTED]>
> Date: Tue, 9 May 2000 08:23:11 +0300 (EEST)
> To: Ray Daoud <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], Jacek Slaboszewicz <[EMAIL PROTECTED]>
> Subject: Re: Windows Client SFTP
>
> Ray Daoud writes:
> : On Tue, 9 May 2000, Sami Lehtinen wrote:
> : > sh, bash and zsh (I presume ksh also behaves like this) don't source
> : > their rc-files, if they are non-interactive (ie. executing command).
> : >
> : > tcsh (atleast, and very probably csh (I can't verify this right this
> : > minute)) source their rc-files even if non-interactive. If they are
> : > given the argument "-f", they won't read the dot-rc files at startup.
> :
> : Yep, csh does this as well...
> :
> : > Suggestions? Should I check if the shell is "*csh" and give the
> : > argument "-f", if executing a command?
> :
> : That was exactly what I was thinking. I tried "csh -f" wrapper
> : script to call from sshd2_config, but apparently the damage is done
> : before the sftp-server process is called...
>
> That wouldn't work. The sftp-server (or whatever sub-system you're
> running) is executed with execve() in the following manner:
>
> % <user-shell> -c <sub-system>
>
> ad indeed, tcsh and csh have already destroyed the filexfer protocol
> stream. (as in "outputted junk to it...")
>
> : A patch for this would be _much_ appreciated...
>
> I'll see what we can cook up.
>
> Hmm, and of course this behaviour should be configurable... *sigh*
>
> --
> [[EMAIL PROTECTED] -- Sami J. Lehtinen -- [EMAIL PROTECTED]]
> [work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl]
> [SSH Communications Security Ltd. http://www.ssh.com/]
>
