Re: bash --norc

[Kai Großjohann]

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[1] (I have
> little idea how[2]), 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).
>
>
> [1] 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.
>
> [2]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
> again.
>
> 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
tried anyway.

What do people think?

Any people out there who would be willing to test various candidate
solutions to see their viability?

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)