How to avoid kickout from SSH when script fail

Question

Please forgive my basic unix/linux scripting skill and poor English

I am testing a script in the Linux VM, let's say it is work.sh. So I have to ssh to the VM

ssh [email protected] 

with my access, then I need to run the script in my home folder

[[email protected] ~]. work.sh param1 param2

When something goes wrong in the batch script, I can see the error but also get kicked out of the VM/ssh session

Connection to [email protected] closed.

so I have to log back in.

I tried nohup, but I also like to have any error/log output to the console. What is the better way to handle this situation

Answer 1

Sounds like there is a set -e in the script. Closing the shell would be expected behaviour if a sourced script (run with . scriptname) throws an error with that setting enabled.

Without any insight into the script, I can't say for sure that you shouldn't be running it with . but it's an unusual way to do things.

I would try running it with:

./work.sh param1 param2

If you are trying to get past a missing execute bit preventing you from running the script, you could try:

$SHELL ./work.sh param1 param2

Alternatively you could start an additional shell and run as you are at present -- this might let you see an error message

$SHELL
. work.sh param1 param2

Answer 2

with my access, then I need to run the script in my home folder
[[email protected] ~]. work.sh param1 param2

There are two ways to invoke an script : the "normal call" and the "dot call" or "sourcing":

$ /path/to/executable
$ . /path/to/executable

The difference is: The first variant will make the OS start a new process (a child process of your shell), load and execute the script there and when the so loaded script ends its run the process is closed again - and you are back in your shell process, which will in all likelyhood present you another prompt.

The second variant acts similar, but with a vital difference: there is no child process created but the script is loaded and executed in the current process. I am not sure what work.sh does (if you want a comment on that you should have posted its contents), but my suspicion is it leaves your login shell somehow and this is what causes the disconnect. Don't start it with a dot in front and you most probably won't experience the disconnects again.

BONUS Information
In my experience beginners learn best and fastest when they can be shown some experiment to see the effect of something. So here it is:

You can see the difference between dot-execution and normal execution by writing the following script and saving it as "my_script.sh":

#!/bin/bash
my_x="abc"
my_y="def"

Don't forget to make it executable (chmod 754 my_script.sh) and execute the script the normal way, then display the content of the two defined variables:

$ ./my_script.sh
$ echo $my_x $my_y

The effect you will see is: nothing - the variables are not set. The reason is simple: at the start of the script another process was started, the definition of the variables happened there and they vanished again when the process was closed because they were part of that environment, not yours.

Now run the same script with dot-execution:

$ . ./my_script.sh
$ echo $my_x $my_y
abc def

You will notice that this time the variables are indeed set: the reason is that the script was not executed in some new process but in yours - hence the variable definition took place in your environment and subsequently are still there.