When you run a command over SSH, your shell executes a different set of startup files than when you connect interactively to the server. So the fundamental problem is really that the path where this tool is installed is not in your PATH
when you connect via ssh
from a script.
A common but crude workaround is to force the shell to read in the file with the PATH
definition you want; but of course that basically requires you to know at least where the correct PATH
is set, so you might as well just figure out where exactly the tool is installed in the first place anyway.
ssh server '. .bashrc; type -all solsql'
(assuming that the PATH
is set up in your .bashrc
; and ignoring for the time being the difference between executing stuff as yourself and as root
. The dot and space before .bashrc
are quite significant. Notice also how we use the POSIX command type
rather than the brittle which
command which should have died a natural but horrible death decades ago).
If you have a good idea of where the tool might be installed, perhaps instead do
subprocess.check_output(['ssh', 'root@' + ip, '''
for path in /opt/solidDB/*/bin /usr/local/bin /usr/bin; do
test -x "$path/solsql" || continue
echo "$path"
exit 0
done
exit 1'''])
Notice how we also avoid the (here, useless) shell=True
. Perhaps see also Actual meaning of 'shell=True' in subprocess