[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bash --norc
From: |
Tim Connors |
Subject: |
bash --norc |
Date: |
Sat, 19 Oct 2002 00:25:45 +1000 (EST) |
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?
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 :)
--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
"I give up," said Pierre de Fermat's friend. "How DO you keep a
mathematician busy for 350 years?"
- bash --norc,
Tim Connors <=