259

When I use exit command in a shell script, the script will terminate the terminal (the prompt). Is there any way to terminate a script and then staying in the terminal?

My script run.sh is expected to execute by directly being sourced, or sourced from another script.

EDIT: To be more specific, there are two scripts run2.sh as

...
. run.sh
echo "place A"
...

and run.sh as

...
exit
...

when I run it by . run2.sh, and if it hit exit codeline in run.sh, I want it to stop to the terminal and stay there. But using exit, the whole terminal gets closed.

PS: I have tried to use return, but echo codeline will still gets executed....

Richard
  • 14,642
  • 18
  • 56
  • 77
  • 5
    I really, really, really have to ask: why are you using exit in a sourced script? – Ignacio Vazquez-Abrams Mar 09 '12 at 20:44
  • 4
    the exit command should not terminate your terminal session/login. if you use `exit 0` to terminate the script after success, when you run your script ex: `./test.sh` you should see the output but your console will remain open. – Ben Ashton Mar 09 '12 at 20:45
  • You could use the `shell` command, that opens in fact a shell terminal. My own experience however is that this doesn't happen with `exit`. Exit normally gives back the control to the parent script. – Willem Van Onsem Mar 09 '12 at 20:45
  • This makes no sense to me. It only kills process (aka the terminal) if called from the top level (globally.) And why would you do that? At the top level, it exits gracefully by itself after completing anyway. Am I missing something here? – Nate T Aug 23 '21 at 05:35
  • 5
    @IgnacioVazquez-Abrams your comment does little except to make the OP feel bad. It sort of hints that the problem has to do with sourcing the script, but why not just say that instead of making someone feel bad for trying it? After all, it's a kind of subtle point that exec and source run differently in terms of shell. Ah, but I see that five people have joined you in being mean... – M Katz Oct 17 '21 at 08:39

17 Answers17

370

The "problem" really is that you're sourcing and not executing the script. When you source a file, its contents will be executed in the current shell, instead of spawning a subshell. So everything, including exit, will affect the current shell.

Instead of using exit, you will want to use return.

Dominik Honnef
  • 17,937
  • 7
  • 41
  • 43
  • 2
    Here's another explanation that I found helpful: http://askubuntu.com/a/53179/148337 – 3cheesewheel Jul 26 '13 at 19:51
  • 2
    Although correct, this is not a great answer. It ignores that the calling script may declare variables or functions that that called script needs access to. Better to explain how to set a return code and then process it in `runs.sh` @ruakh has the better answer to this question. – MikeSchinkel Aug 28 '16 at 17:08
  • 7
    What if the function is a nested call? i.e. a calls b, b calls c, c wants to immediately exit a and b. – Michael Sep 08 '16 at 22:00
  • 1
    Source is almost the same as copy paste. It's better to use `sh – Peter Chaula Aug 24 '17 at 20:00
  • bash: return: can only `return' from a function or sourced script – f01 Mar 18 '21 at 01:19
  • `return` returns from the function call but does no terminate the running script code. – alper Aug 10 '21 at 14:50
52

Yes; you can use return instead of exit. Its main purpose is to return from a shell function, but if you use it within a source-d script, it returns from that script.

As §4.1 "Bourne Shell Builtins" of the Bash Reference Manual puts it:

     return [n]

Cause a shell function to exit with the return value n. If n is not supplied, the return value is the exit status of the last command executed in the function. This may also be used to terminate execution of a script being executed with the . (or source) builtin, returning either n or the exit status of the last command executed within the script as the exit status of the script. Any command associated with the RETURN trap is executed before execution resumes after the function or script. The return status is non-zero if return is used outside a function and not during the execution of a script by . or source.

ruakh
  • 175,680
  • 26
  • 273
  • 307
  • 6
    `return` can ONLY be used from a function. If you use `return` and execute it as a shell script (e.g. `sh run.sh`), bash will report an error - `return: can only `return' from a function or sourced script` – Tzunghsing David Wong Sep 21 '18 at 00:32
  • 2
    @TzungsingDavidWong: You do realize that the bulk of this answer is a quotation from the official reference manual? And that the error-message you quote agrees with this answer instead of with your claim? – ruakh Sep 21 '18 at 00:51
  • 1
    l am not disagree with you. I simply want to point out that `return` won't work if the script is run as a shell script and not executed by . (or `source`). BTW, where can I find the document about `source -d`? – Tzunghsing David Wong Sep 21 '18 at 07:50
  • 1
    There are times when I will run my scripts dotsource and other times when I will run the same scripts as a shell script. So, is there a way to detect internally to a script, whether it has been run dotsourced, or whether it has been run as a shell script? That way, I can detect how it is being invoked and handle that situation appropriately? – YorSubs Dec 05 '20 at 07:58
  • @YorSubs: There's no reliable way to detect that. I have some ideas for how to make a good guess, and some ideas about how the script can handle this without needing to detect that; but before I offer those ideas . . . usually, a script is intended to be run a certain way, and is written accordingly, and so that's how you run it. Can you tell me a bit about your use-case for a script that can be run in those two very different ways? (That will help me identify which of my ideas, if any, are likely to satisfy your needs.) – ruakh Dec 05 '20 at 23:28
  • I have a script called `.custom` where I keep my custom profile settings (I do this specifically so that the standard profiles are not messed up and this is only called from `.bashrc` if the session is interactive). In my git project for this, I sometimes dotsource that file to intergrade into my environment, or can run it non-dotsourced. I might not be doing things in the most efficient way, but it would be useful to me (in this current situation) if I can test that inside the script. – YorSubs Dec 05 '20 at 23:51
  • 1
    @YorSubs: But if it sets profile settings, does that even have any effect when the script is run as a normal script? – ruakh Dec 06 '20 at 03:30
  • Indeed, I think you are right, I do not need this. I guess I just need to know clearly how to exit a script without exiting the shell a) for running a bash script (in which case, use `exit`), or b) when running a dotsourced script (in which case, use `return`). – YorSubs Dec 06 '20 at 20:46
19

You can add an extra exit command after the return statement/command so that it works for both, executing the script from the command line and sourcing from the terminal.

Example exit code in the script:

   if [ $# -lt 2 ]; then
     echo "Needs at least two arguments"
     return 1 2>/dev/null
     exit 1
   fi

The line with the exit command will not be called when you source the script after the return command.

When you execute the script, return command gives an error. So, we suppress the error message by forwarding it to /dev/null.

David Kariuki
  • 1,522
  • 1
  • 15
  • 30
noname
  • 191
  • 1
  • 3
12

Instead of running the script using . run2.sh, you can run it using sh run2.sh or bash run2.sh

A new sub-shell will be started, to run the script then, it will be closed at the end of the script leaving the other shell opened.

David Kariuki
  • 1,522
  • 1
  • 15
  • 30
Viorel Mirea
  • 371
  • 3
  • 6
  • If so, then why the second parameter `sh "." run2.sh`? – CHAN Nov 04 '15 at 17:01
  • @H0WARD You're right I forgot to remove the dots. I have edited the answer now. – Viorel Mirea Nov 04 '15 at 19:43
  • 3
    The OP explicitly states source as a requirement. – Coder Guy Dec 15 '16 at 22:32
  • @JonathanNeufeld Yes, but I, and many others like me, found this post because I habitually source bash scripts and was wondering why I kept killing my terminal when testing a script someone else wrote. TIL the critical difference between `source` and `sh` is shell / sub-shell. (NB: I prefer Perl for most non-trivial scripts, hence my ignorance of this issue until now.) – Medlock Perlman Sep 18 '21 at 01:39
5

Actually, I think you might be confused by how you should run a script.

If you use sh to run a script, say, sh ./run2.sh, even if the embedded script ends with exit, your terminal window will still remain.

However if you use . or source, your terminal window will exit/close as well when subscript ends.

for more detail, please refer to What is the difference between using sh and source?

Ashley Frieze
  • 4,993
  • 2
  • 29
  • 23
karl li
  • 1,316
  • 15
  • 19
3

To write a script that is secure to be run as either a shell script or sourced as an rc file, the script can check and compare $0 and $BASH_SOURCE and determine if exit can be safely used.

Here is a short code snippet for that

[ "X$(basename $0)" = "X$(basename $BASH_SOURCE)" ] && \
    echo "***** executing $name_src as a shell script *****" || \
    echo "..... sourcing $name_src ....."
David Kariuki
  • 1,522
  • 1
  • 15
  • 30
Tzunghsing David Wong
  • 1,271
  • 14
  • 10
  • This is a very good answer, even with the quirk that it returns: `basename: unknown option -- b` when sourcing. You should also address the exit and `$name_src` for completeness. An explanation that the checking is done by using s sub-shell should also be stated. – not2qubit Apr 30 '21 at 19:04
3

I had the same problem and from the answers above and from what I understood what worked for me ultimately was:

  1. Have a shebang line that invokes the intended script, for example,

    #!/bin/bash uses bash to execute the script

I have scripts with both kinds of shebang's. Because of this, using sh or . was not reliable, as it lead to a mis-execution (like when the script bails out having run incompletely)

The answer therefore, was

    • Make sure the script has a shebang, so that there is no doubt about its intended handler.
    • chmod the .sh file so that it can be executed. (chmod +x file.sh)
    • Invoke it directly without any sh or .

      (./myscript.sh)

Hope this helps someone with similar question or problem.

David Kariuki
  • 1,522
  • 1
  • 15
  • 30
gk_2000
  • 194
  • 3
  • 16
3

This is just like you put a run function inside your script run2.sh. You use exit code inside run while source your run2.sh file in the bash tty. If the give the run function its power to exit your script and give the run2.sh its power to exit the terminator. Then of cuz the run function has power to exit your teminator.

    #! /bin/sh
    # use . run2.sh

    run()
    {
        echo "this is run"
        #return 0
        exit 0
    }

    echo "this is begin"
    run
    echo "this is end"

Anyway, I approve with Kaz it's a design problem.

Umae
  • 445
  • 2
  • 5
  • Not clear from the text what this answer attempts to do, but it certainly does not solve the question at hand. – Luís de Sousa Jan 14 '20 at 08:15
  • I don't see how this reply provides anything useful. The OP problem was related to *sourcing* a script that uses 'exit' instead of 'return' . – PRouleau May 06 '22 at 21:38
2

I think that this happens because you are running it on source mode with the dot

. myscript.sh

You should run that in a subshell:

/full/path/to/script/myscript.sh

'source' http://ss64.com/bash/source.html

JBoy
  • 5,398
  • 13
  • 61
  • 101
2

It's correct that sourced vs. executed scripts use return vs. exit to keep the same session open, as others have noted.

Here's a related tip, if you ever want a script that should keep the session open, regardless of whether or not it's sourced.

The following example can be run directly like foo.sh or sourced like . foo.sh/source foo.sh. Either way it will keep the session open after "exiting". The $@ string is passed so that the function has access to the outer script's arguments.

#!/bin/sh
foo(){
    read -p "Would you like to XYZ? (Y/N): " response;
    [ $response != 'y' ] && return 1;
    echo "XYZ complete (args $@).";
    return 0;
    echo "This line will never execute.";
}
foo "$@";

Terminal result:

$ foo.sh
$ Would you like to XYZ? (Y/N): n
$ . foo.sh
$ Would you like to XYZ? (Y/N): n
$ |
(terminal window stays open and accepts additional input)

This can be useful for quickly testing script changes in a single terminal while keeping a bunch of scrap code underneath the main exit/return while you work. It could also make code more portable in a sense (if you have tons of scripts that may or may not be called in different ways), though it's much less clunky to just use return and exit where appropriate.

Beejor
  • 8,606
  • 1
  • 41
  • 31
1

Also make sure to return with expected return value. Else if you use exit when you will encounter an exit it will exit from your base shell since source does not create another process (instance).

coder23
  • 43
  • 5
1

Improved the answer of Tzunghsing, with more clear results and error re-direction, for silent usage:

#!/usr/bin/env bash

echo -e "Testing..."

if [ "X$(basename $0 2>/dev/null)" = "X$(basename $BASH_SOURCE)" ]; then
    echo "***** You are Executing $0 in a sub-shell."
    exit 0
else
    echo "..... You are Sourcing $BASH_SOURCE in this terminal shell."
    return 0
fi

echo "This should never be seen!"

Or if you want to put this into a silent function:

function sExit() {
    # Safe Exit from script, not closing shell.
    [ "X$(basename $0 2>/dev/null)" = "X$(basename $BASH_SOURCE)" ] && exit 0 || return 0
}

...

# ..it have to be called with an error check, like this: 
sExit && return 0

echo "This should never be seen!"

Please note that:

  • if you have enabled errexit in your script (set -e) and you return N with N != 0, your entire script will exit instantly. To see all your shell settings, use, set -o.
  • when used in a function, the 1st return 0 is exiting the function, and the 2nd return 0 is exiting the script.
not2qubit
  • 14,531
  • 8
  • 95
  • 135
0

If a command succeeded successfully, the return value will be 0. We can check its return value afterwards.

Is there a “goto” statement in bash?

Here is some dirty workaround using trap which jumps only backwards.


#!/bin/bash
set -eu
trap 'echo "E: failed with exitcode $?" 1>&2' ERR

my_function () {
    if git rev-parse --is-inside-work-tree > /dev/null 2>&1; then
        echo "this is run"
        return 0
    else
        echo "fatal: not a git repository (or any of the parent directories): .git"
        goto trap 2> /dev/null
    fi
}

my_function
echo "Command succeeded"  # If my_function failed this line is not printed

Related:

alper
  • 2,919
  • 9
  • 53
  • 102
0

I couldn't find solution so for those who want to leave the nested script without leaving terminal window:

# this is just script which goes to directory if path satisfies regex
wpr(){
    leave=false
    pwd=$(pwd)
    if [[ "$pwd" =~ ddev.*web ]]; then
        # echo "your in wordpress instalation"
        wpDir=$(echo "$pwd" | grep -o  '.*\/web')
        cd $wpDir
        return
    fi
    echo 'please be in wordpress directory'
    # to leave from outside the scope
    leave=true
    return
}

wpt(){
    # nested function which returns $leave variable
    wpr
    
    # interupts the script if $leave is true
    if $leave; then
        return;
    fi
    echo 'here is the rest of the script, executes if leave is not defined'
}
Paweł Witek
  • 171
  • 11
0

I have no idea whether this is useful for you or not, but in zsh, you can exit a script, but only to the prompt if there is one, by using parameter expansion on a variable that does not exist, as follows.

${missing_variable_ejector:?}

Though this does create an error message in your script, you can prevent it with something like the following.

{ ${missing_variable_ejector:?} } 2>/dev/null
sicjedi
  • 11
  • 3
0

if your terminal emulator doesn't have -hold you can sanitize a sourced script and hold the terminal with:

#!/bin/sh
sed "s/exit/return/g" script >/tmp/script
. /tmp/script
read

otherwise you can use $TERM -hold -e script

technosaurus
  • 7,676
  • 1
  • 30
  • 52
-3

1) exit 0 will come out of the script if it is successful.

2) exit 1 will come out of the script if it is a failure.

You can try these above two based on ur req.

Teja
  • 13,214
  • 36
  • 93
  • 155