Mosh ignores .bashrc when starting remote server #465
Comments
|
If ssh -S none -o "ProxyCommand='/inside/home/anovak/.local/bin/mosh' --fake-proxy -- %h %p" -n -tt localhost -- "mosh-server 'new' '-c' '256' '-s' '-l' 'LANG=en_US.UTF-8'"I’m assuming that command behaves differently than the one you ran. Maybe you can figure out why. I’m guessing that the |
|
I cannot confirm that. Works for me in Fedora. |
|
Where is the documentation for the -n and -tt options being used here? I How would this interact with dotfiles. My dotfiles do indeed include some Could someone post working dotfiles? On Fri, Nov 1, 2013 at 9:20 AM, Lukáš Zapletal notifications@github.comwrote:
|
|
The -n and -tt options ain't options to bash, its options to ssh. Its up to your server to handle your .dotfiles, and mosh doens't care if your login shell is bash, tcsh or something else. You probably have some weird if-case checking something in your .bashrc or your global bash startup. |
|
I've pared my dotfiles down to the following: I believe the problem is the When ssh is asked to allocate a tty, neither of the two dotfiles defining the $PATH to include mosh-server is run. I am now looking into whether this is expected behavior for the ssh -tt option, and how it might be worked around. Does |
|
Normally ssh -t means "allocate a pty on the server side", which usually If you run a command then the server might not run a login shell. What you |
|
Yes, on my system (Ubuntu), and I expect most others,
What is your server running? Is it possible that your default shell is not actually |
|
The server I am connecting to runs RHEL 5. My default shell is indeed bash. Unfortunately, there is by default no way (as far as I can tell) for a normal user to set $BASH_ENV for a non-interactive non-login shell invoked over SSH; environment variables defined in Is there a way to instruct |
|
Aha, that’s what I’d forgotten about. I think you now have a correct diagnosis here. Note that the shell that would later spawned by The |
|
When/if we can assume that the mosh-server have 45bba44, we can drop the -tt part. If you try to run without -tt against a mosh-server from before that, it will die on a assertion. |
|
Okay. 45bba44 is not part of any released Mosh version yet, so that will be a while… |
|
Same here (also a RHEL5) server). I cannot start the server with --server because I need to set other paths and librariers to make mosh-server work. Manually patching /usr/bin/mosh (placing a copy in ~/bin) to drop the "-tt" makes it work. |
In case someone reads this later on, one solution here is to use --server to point to a wrapper that sets up those paths and libraries, then runs mosh-server. |
|
Just ran into this issue. I'm also |
|
@smaslennikov Er, I want to be clear for the benefit of anyone who might copy-and-paste that without understanding what it does that we do not recommend setting the setuid bit ( The easiest way to get Mosh working on CentOS is to install the |
|
@andersk welp, that's what I did. $ yum list installed | grep mosh
mosh.x86_64 1.3.0-1.el7 @epelEdit: I'm full of shame for using u+s without proper research. As others have suggested elsewhere, |
|
Problems with |
|
Closing in favor of #819 |
I can start up mosh-server on the remote host with my approximation of what I think mosh is supposed to be doing:
I have mosh installed with a prefix, but my .bashrc (which runs for non-login shells like the above) adds it to my PATH.
However, mosh somehow is managing to invoke a remote bash that doesn't get the PATH defined in my .bashrc:
The key line there is "bash: mosh-server: command not found".
Also, if I put an echo at the top of my .bashrc, it comes through when I run non-login ssh manually, but not when I try to connect with mosh.
I suspect that mosh is broken somehow and is telling the remote system to not start a proper non-login shell.
The text was updated successfully, but these errors were encountered: