[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bash --norc
Re: bash --norc
Sat, 19 Oct 2002 15:59:45 +0200
Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.3.50 (i686-pc-linux-gnu)
Tim Connors <address@hidden> writes:
> I just used multihop and logged into an old SunOS system, where /bin/sh
> does not expand ~root to /root, so it goes and uses bash. This is fine,
> but bash there is fairly old, and does not accept --norc. However, it does
> accept -norc, and works as intended.
> I then found out that every other bash I have access to will accept -norc
> as a synonym for --norc, even though it is not documented. So, in order to
> increase portability, perhaps the default tramp-sh-extra-args should be
> "-norc" instead? Maybe even "-norc -noprofile" for those really broken
> setups that do silly things (ie mine) in the .bash_profile file?
I've now changed Tramp to use "-norc -noprofile".
> But before you fix & close this bug, this created one more interesting
> effect. Because tramp tried to exec bash --norc, it failed, and the second
> ssh session closed, returning control to the first hops (the local
> gateway's) ssh session. Perhaps this needs to be detected (I have
> little idea how), because the session became horribly corrupted at this
> stage (I looked through the logs, and have no idea what happened - all
> these "^H"'s etc popped up).
>  I noticed since upgrading from tramp 1.x, that tramp now echoes "are
> you there" if the remote host doesn't answer in time (or somthing
> similar), and will start a new connection if it appears dead. What happens
> if the remote side dies, returns control to the gateway ssh session, and
> you ask tramp to do another file operation? On my system, because PS1 on
> the gateway is set differently (and tramp didn't bother to set it up,
> because it immediately wanted to ssh elsewhere), the regexp doesn't match
> the reply "are you there\n$ ", so it start a new login to the remotebox.
> Perhaps, what you should do, is as soon as you log into a non-terminal
> hop (my fancy name for the final destination :), set the PS1 to be
> something destinctive, and if that regexp ever appears again, you know the
> terminal ssh session died, and you might as well kill all the ssh sessions
> associated with all the hops to that destination host, and start them all
> I appologise profusely for my non-clearosity of this email, and for the
> fact that I haven't included a patch myself :)
It is very clear indeed, and you are raising a point that I didn't
think of. Whee.
I have another idea: how about changing the multi-hop methods to send
"exec foo" instead of just "foo" to do the next hop? That ought to
take care of things automatically.
But in general, the multi-hop methods have too little fail-safety
built-in. Normally, if you mistype a password, Tramp should grok
this and try again. Of course, the "exec" suggestion makes the
situation worse: it will be very difficult to try again with "exec".
A minor issue for your change-PS1 suggestion is that multi-hop now
needs to start a Bourne-ish shell on every hop. That might clobber
$PATH (or equivalent) and thus lead to problems finding the right
program for logging into other locations :-/ But maybe it should be
What do people think?
Any people out there who would be willing to test various candidate
solutions to see their viability?
~/.signature is: umop ap!sdn (Frank Nobis)
- bash --norc, Tim Connors, 2002/10/18
- Re: bash --norc,
Kai Großjohann <=