Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
703 views
in Technique[技术] by (71.8m points)

bash - Determining whether shell script was executed "sourcing" it

Is it possible for a shell script to test whether it was executed through source? That is, for example,

$ source myscript.sh
$ ./myscript.sh

Can myscript.sh distinguish from these different shell environments?

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Reply

0 votes
by (71.8m points)

I think, what Sam wants to do may be not possible.

To what degree a half-baken workaround is possible, depends on...

  • ...the default shell of users, and
  • ...which alternative shells they are allowed to use.

If I understand Sam's requirement correctly, he wants to have a 'script', myscript, that is...

  1. ...not directly executable via invoking it by its name myscript (i.e. that has chmod a-x);
  2. ...not indirectly executable for users by invoking sh myscript or invoking bash myscript
  3. ...only running its contained functions and commands if invoked by sourcing it: . myscript

The first things to consider are these

  1. Invoking a script directly by its name (myscript) requires a first line in the script like #!/bin/bash or similar. This will directly determine which installed instance of the bash executable (or symlink) will be invoked to run the script's content. This will be a new shell process. It requires the scriptfile itself to have the executable flag set.
  2. Running a script by invoking a shell binary with the script's (path+)name as an argument (sh myscript), is the same as '1.' -- except that the executable flag does not need to be set, and said first line with the hashbang isn't required either. The only thing needed is that the invoking user needs read access to the scriptfile.
  3. Invoking a script by sourcing its filename (. myscript) is very much the same as '1.' -- exept that it isn't a new shell that is invoked. All the script's commands are executed in the current shell, using its environment (and also "polluting" its environment with any (new) variables it may set or change. (Usually this is a very dangerous thing to do: but here it could be used to execute exit $RETURNVALUE under certain conditions....)

For '1.':
Easy to achieve: chmod a-x myscript will prevent myscript from being directly executable. But this will not fullfill requirements '2.' and '3.'.

For '2.' and '3.':
Much harder to achieve. Invokations by sh myscript require reading privileges for the file. So an obvious way out would seem to chmod a-r myscript. However, this will also dis-allow '3.': you will not be able to source the script either.

So what about writting the script in a way that uses a Bashism? A Bashism is a specific way to do something which other shells do not understand: using specific variables, commands etc. This could be used inside the script to discover this condition and "do something" about it (like "display warning.txt", "mailto admin" etc.). But there is no way in hell that this will prevent sh or bash or any other shell from reading and trying to execute all the following commands/lines written into the script unless you kill the shell by invoking exit.

Examples: in Bash, the environment seen by the script knows of $BASH, $BASH_ARGV, $BASH_COMMAND, $BASH_SUBSHELL, BASH_EXECUTION_STRING... . If invoked by sh (also if sourced inside a sh), the executing shell will see all these $BASH_* as empty environment variables. Again, this could be used inside the script to discover this condition and "do something"... but not prevent the following commands from being invoked!

I'm now assuming that...

  1. ...the script is using #!/bin/bash as its first line,
  2. ...users have set Bash as their shell and are invoking commands in the following table from Bash and it is their login shell,
  3. ...sh is available and it is a symlink to bash or dash.

This will mean the following invokations are possible, with the listed values for environment variables

vars+invok's   | ./scriptname | sh scriptname | bash scriptname | . scriptname
---------------+--------------+---------------+-----------------+-------------
$0             | ./scriptname | ./scriptname  | ./scriptname    | -bash
$SHLVL         | 2            | 1             | 2               | 1
$SHELLOPTS     | braceexpand: | (empty)       | braceexpand:..  | braceexpand:
$BASH          | /bin/bash    | (empty)       | /bin/bash       | /bin/bash
$BASH_ARGV     | (empty)      | (empty)       | (empty)         | scriptname
$BASH_SUBSHELL | 0            | (empty)       | 0               | 0
$SHELL         | /bin/bash    | /bin/bash     | /bin/bash       | /bin/bash
$OPTARG        | (empty)      | (empty)       | (emtpy)         | (emtpy)

Now you could put a logic into your text script:

  • If $0 is not equal to -bash, then do an exit $SOMERETURNVALUE.

In case the script was called via sh myscript or bash myscript, then it will exit the calling shell. In case it was run in the current shell, it will continue to run. (Warning: in case the script has any other exit statements, your current shell will be 'killed'...)

So put into your non-executable myscript.txt near its beginning something like this may do something close to your goal:

echo BASH=$BASH
test x${BASH} = x/bin/bash && echo "$? :    FINE.... You're using 'bash ...'"
test x${BASH} = x/bin/bash || echo "$? :    RATS !!! -- You're not using BASH and I will kick you out!"
test x${BASH} = x/bin/bash || exit 42
test x"${0}" = x"-bash"    && echo "$? :    FINE.... You've sourced me, and I'm your login shell."
test x"${0}" = x"-bash"    || echo "$? :    RATS !!! -- You've not sourced me (or I'm not your bash login shell) and I will kick you out!"
test x"${0}" = x"-bash"    || exit 33

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
OGeek|极客中国-欢迎来到极客的世界,一个免费开放的程序员编程交流平台!开放,进步,分享!让技术改变生活,让极客改变未来! Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...