Mfcttrf

If I try to start python in a bash script, the script will stop running and no commands will execute after "Python" is called. In this simple example, "TESTPRINT" will not be printed. It seems like the script just stops.

#!/bin/bash

python

print("TESTPRINT")

Echo

How do I make the script continue running after going into Python? I believe I had the same problem a few years ago after writing a script that first needed to shell into an Android Phone. Cant remember how I fixed it that time.

To run a set of Python commands from a bash script, you must give the Python interpreter the commands to run, either from a file (Python script), as in

#!/bin/bash

# Create script as "script.py"
cat >script.py <<'END_SCRIPT'
print("TESTPRINT")
END_SCRIPT

# Run script.py
python script.py

... or directly via some form of redirection, for example a here-document:

#!/bin/bash

python - <<'END_SCRIPT'
print("TESTPRINT")
END_SCRIPT

What this does is running python - which instructs the Python interpreter to read the script from standard input. The shell then sends the text of the Python script (delimited by END_SCRIPT in the shell script) to the Python process' standard input stream.

Note that the two bits of code above are subtly different in that the second script's Python process has its standard input connected to the script that it's reading, while the first script's Python process is free to read data other than the script from standard input. This matters if your Python code reads from standard input.

Python can also take a set of commands from the command line directly with its -c option:

#!/bin/bash

python -c 'print("TESTPRINT")'

What you can't do is to "switch to Python" in the middle of a bash script.

The commands in a script is executed by bash one after the other, so your original script would start Python in interactive mode, temporarily suspending the execution of the bash script until the Python process terminates. The script would then try to execute print("TESTPRINT") as a shell command.

It's a similar issue with using ssh like this in a script:

ssh user@server
cd /tmp
ls

(which may possibly be similar to what you say you tried a few years ago).

This would not connect to the remote system and run the cd and ls commands there. It would start an interactive shell on the remote system, and once that shell has terminated (giving control back to the script), cd and ls would be run locally.

Instead, to execute the commands on a remote machine, use

ssh user@server "cd /tmp; ls"

(This is a lame example, but you may get the point).