4

I am trying to execute a script on a remote machine in screen session using ssh. The command I use is: 

ssh -t MYSERVER "cd tempdirXYZ; screen Myscript.sh"

When I execute this, I see a screen window for a few seconds displaying 

cannot exec 'Myscript.sh': No such file or directory

I use bash on the remote machine and the script is placed in my ~/bin folder. It seems that when I run the above command, my bash files are not being sourced. I am not even sure if bash is run at all.

Is there any way to make this work without changing the command? The remote machine is running Ubuntu.

Smith
  • 41

3 Answers3

4

I just realised you said ~/bin and not /bin.

You need to execute the following to add the directory to the system's PATH variable:

export PATH=\$PATH:/home/<username>/bin

This should allow you to run the script as above. If not it's likely not marked as executable so run:

chmod +x ~/bin/Myscript.sh
I_GNU_it_all_along
  • 1,712
3

There is little you can do if you can't change the command. The ~/.bashrc file should be getting processed during this command execution.

What might be happening is that you have a conditional exit statement in .bashrc , usually right near the beginning, which will exit if the current shell is detected to be non-interactive ( in this case it is). Sometimes the script will check if the primary prompt variable PS1 is set; which is a common but ugly method to evaluate for an interactive vs a non-interactive shell. In this case when PS1 is not set the remainder of .bashrc is not parsed.

I would check if that is the case - use some simple debugging techniques to see if .bashrc is sourced and if it ends early (eg echo statements). You would need to modify .bashrc on the remote machine to address that, and that may break other things such as scp and sftp. Or you could just set PS1 in your remote command.

There are any number of workarounds if you can modify the remote command:

  1. Add the items necessary to run the script to a separate bash file. Source it directly in your command.
  2. Use the full paths in the command and in the remote script. I don't know what other env dependencies besides PATH you have but obviously those have to be addressed as well.
  3. On the remote machine populate ~/.ssh/environment with all necessary environmental variables, aliases, functions etc. Modify the ssh config file /etc/ssh/shhd to make sure that the setting PermitUserEnvironmentis enabled; otherwise this won't work.
  4. Add the environmental variable settings to the command, eg "export PATH=\$PATH:/home/you/bin;..." Escaping PATH ensures that its the remote version we are adding to, preventing expansion prior to sending the command.

If none of this will work please describe your constraints in more detail.

Community
  • 1
Argonauts
  • 735
  • Whether .bashrc is executed when logging in over SSH depends on a build-time option (SSH_SOURCE_BASHRC). For example Ubuntu turns it on (so this will work for Smith if they've kept bash as their shell as per the Ubuntu default), but FreeBSD doesn't. – Gilles 'SO- stop being evil' Sep 06 '16 at 09:21
  • Do you know if the --norc and --withrc= arguments to ssh can be used to 'ignore' that compilation argument (allowing a semi portable approach) or if they are generally unsupported / ignored as the gnu documentation seems to indicate? Not directly related to question; mostly curious. – Argonauts Sep 06 '16 at 09:54
  • Over SSH, you don't get a chance to pass arguments to the login shell. – Gilles 'SO- stop being evil' Sep 06 '16 at 10:06
  • What is executed or not upon an ssh login could also be modified via PAM settings. – rackandboneman Sep 06 '16 at 15:43
0

To see what file type it's recognized as

file myscript.sh

Set User + Execute Permissions 

chmod u+x Myscript.sh
CJ Dana
  • 231