Linux – Execute command on remote server via ssh

linuxshellssh

I am attempting to execute a command on a remote linux server via an ssh command on a local server like this:

ssh myremoteserver 'type ttisql'

where ttisql is an executable on the path of my remote machine.

The result of running this is:

bash: line 0: type: ttisql: not found

When I simply connect first and do:

ssh myremoteserver

and then enter the command:

[myuser@myremoteserver~]$: type ttisql

I get back the path of the ttisql exe as I would expect.

The odd thing is that when I execute the first command in my beta environment it works as expected and returns the path of the exe. In the beta scenario, machine A is connecting to remote machine B but both machines are onsite and the ssh command connects to the remote machine quickly.

The problem is encountered in our production environment when machine A is local and machine B is offsite and the ssh command takes a second or two to connect.

The only difference I can see is the time it takes the production ssh to connect. The path on the remote system is correct since the command works if entered after the initial connection.

Can anyone help me understand why this simple command would work in one environment and not the other? Could the problem be related to the time it takes to connect via ssh?

Best Answer

The environment can be different in a non-interactive session (ssh command) from an interactive session (ssh, then command). Try echo $PATH in both cases.

ssh myremoteserver 'echo $PATH'

ssh myremoteserver
[myuser@myremoteserver~]$: echo $PATH

If they differ, look in all startup script for some differentiated behavior based on $PS1 or $-

Related Solutions

Bash – Getting ssh to execute a command in the background on target machine

I had this problem in a program I wrote a year ago -- turns out the answer is rather complicated. You'll need to use nohup as well as output redirection, as explained in the wikipedia artcle on nohup, copied here for your convenience.

Nohuping backgrounded jobs is for example useful when logged in via SSH, since backgrounded jobs can cause the shell to hang on logout due to a race condition [2]. This problem can also be overcome by redirecting all three I/O streams:
nohup myprogram > foo.out 2> foo.err < /dev/null &

Python – How to execute a program or call a system command

Use the subprocess module in the standard library:

import subprocess
subprocess.run(["ls", "-l"])

The advantage of subprocess.run over os.system is that it is more flexible (you can get the stdout, stderr, the "real" status code, better error handling, etc...).

Even the documentation for os.system recommends using subprocess instead:

The subprocess module provides more powerful facilities for spawning new processes and retrieving their results; using that module is preferable to using this function. See the Replacing Older Functions with the subprocess Module section in the subprocess documentation for some helpful recipes.

On Python 3.4 and earlier, use subprocess.call instead of .run:

subprocess.call(["ls", "-l"])

Best Answer

Related Solutions

Bash – Getting ssh to execute a command in the background on target machine

Python – How to execute a program or call a system command

Related Topic