Tim Connors <[EMAIL PROTECTED]> 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) _______________________________________________ Tramp-devel mailing list [EMAIL PROTECTED] http://mail.nongnu.org/mailman/listinfo/tramp-devel
