-1

I am learning shell scripting. My platform is a Debian 10 cloud server. I am testing the following script:

#!/bin/bash
echo This script will exit with an exit status of 0.
exit 0

When I run this it terminates my session! In other words, my terminal window disappears.

My understanding is that exit, run within a shell script, simply terminates the script, not the entire session. Maybe Debian 10 departs from this pattern? If so, how do I return a value from within a shell script on Debian 10?

imz -- Ivan Zakharyaschev
  • 15,462
Argent
  • 209

2 Answers2

2

bash man page:

 .      filename [arguments]
 source filename [arguments]

   Read and execute commands from filename in the current shell environment...

"Sourcing" is the quite generic term here. It means executing the commands from the script file as if you type them one line after the other. You stay in your same bash, and also have all the variables and settings.

"Running" a script includes defining how exactly. Often you call a interpreter. bash script.sh is just like perl script.pl. The suffixes don't matter. What matters is that first "binfmt" line: #!...: ./script or script (if it is in $PATH) is all that is needed.

. script (sourcing)

./script ("running", needs +x)

is not the same, technically.

A shell is your "entire" session, in a way. Ctrl-D has a similar effect. It can be controlled, but since a interactive shell is just like a script, it is logical.

Try

]# ps  
  PID TTY          TIME CMD
18768 pts/1    00:00:00 ps
18994 pts/1    00:00:00 bash
]# bash
]# bash
]# ps
  PID TTY          TIME CMD
18780 pts/1    00:00:00 bash
18781 pts/1    00:00:00 bash
18782 pts/1    00:00:00 ps
18994 pts/1    00:00:00 bash
]# exit
exit
]# exit
exit
]# ps
  PID TTY          TIME CMD
18784 pts/1    00:00:00 ps
18994 pts/1    00:00:00 bash
]#

...to see how you can pile a shell upon another, and also exit.

This all has to do with processes and jobs.

  • Regarding that paragraph about running a script, it seems to state that running bash script.sh would read the hashbang line. It doesn't. bash script.sh runs the script with Bash, perl script.sh runs the script using Perl. Neither is the same as ./script.sh, see: Does the shebang determine the shell which runs the script?. (Except that Perl itself does interpret the hashbang, but that's a quirk of Perl, it's not the common case for a usual interpreter.) – ilkkachu Nov 09 '19 at 07:53
  • yes it is not 100% clear there. I mentioned 'binfmt', because that is the kernel config symbol to support #!. The extension is the "binfmt misc", as I understand. Does not sed also look for options in the first line? –  Nov 09 '19 at 08:05
  • it's in fs/binfmt_script.c and the config option is BINFMT_SCRIPT in Linux. binfmt_misc is different. What first line would sed read for options from? – ilkkachu Nov 09 '19 at 08:26
  • @ilkkachu Here https://unix.stackexchange.com/questions/550829/how-to-do-string-replace-variable-value-on-one-of-lines-appearing-between-two I pasted a sed script; #!/bin/sed is one thing; the -n option the other. –  Nov 09 '19 at 08:36
  • yes, sure, you can put arguments in the hashbang line (or an argument, on Linux). But there it's not sed itself that reads the hashbang line, it's the kernel which reads it, and launches sed with whatever's in there. But if you run somecmd script.sh the kernel doesn't read the hashbang, it's just somecmd that gets launched. But in the case of perl script.sh, Perl itself reads the hashbang, and launches whatever's in there instead, but that's only because Perl is funny that way. (It's a compatibility thing for systems that don't support hashbang, or something.) – ilkkachu Nov 09 '19 at 12:26
1

@steeldriver is right. If I run the script using any of the following it works as desired:

./ex01.sh
sh ex01.sh
bash ex01.sh

Reference:

https://www.cyberciti.biz/faq/run-execute-sh-shell-script/
Argent
  • 209