在bash中，dot命令＆符号是做什么的？

Question

I'm trying to understand a bash script I'm supposed to be maintaining and got stuck. The command is of this form:

. $APP_LOCATION/somescript.sh param1 param2 &

The line is not being called in a loop, not is any return code bening sent back to the calling script from somescript.sh

I know that the "." will make the process run in the same shell. But "&" will spawn off a different process.

That sounds contradictory. What's is really happening here? Any ideas?

Answer 1

The script is running in a background process, but it is a subshell, not a separately-invoked interpreter as it would be without the dot.

That is to say -- the current interpreter forks and then begins running the command (sourcing the script). As such, it inherits shell variables, not just environment variables.

Otherwise the new script's interpreter would be invoked via an execv() call, which would replace the current interpreter with a new one. That's usually the right thing, because it provides more flexibility -- you can't run anything but a script written for the same shell with . or source , after all, whereas starting a new interpreter means that your other script could be rewritten in Python, Perl, a compiled binary, etc without its callers needing to change.

(This is part of why scripts intended to be exec'd, as opposed to than libraries meant to be sourced, should not have filename extensions -- and part of why bash libraries should be .bash , not .sh , such that inaccurate information isn't provided about what kind of interpreter they can be sourced into).

Answer 2

TL;DR

. $APP_LOCATION/somescript.sh param1 param2 &

This sources a script as a background job in the current shell.

Sourcing a Script

In Bash, using . is equivalent to the [source builtin]. The help for the source builtin says (in part):

$ help source
source: source filename [arguments]
    Execute commands from a file in the current shell.

In other words, it reads in your Bash script and evaluates it in the current shell rather than in a sub-shell. This is often important to give a script access to unexported variables.

Background Jobs

The ampersand executes the script in the background using job control . In this case, while the sourced script is evaluated in the context of the current shell, it is executed in a separate process that can be managed using job control builtins .