Bash – Proper way to distribute shell scripts

bashshellshell-script

What is the most proper way to distribute shell scripts, if behaviours of shells can be modified by set and thus are unpredictable?

For example, rm *.txt wouldn't be executed as expected on the environments in which set -f has been run. How should I make sure that rm *.txt removes all text files in a current directory in any environments?

How should I make that sure that shell scripts will run as expected before distributing them in general?

Best Answer

Shell scripts are normally treated as if they were the same as any other kind of executable file, such as binaries, Python scripts, Perl scripts, or any other kind of script. They have a shebang at the top that directs the kernel to execute them through the shell. They are expected to be invoked the same way as any other command.

As such, a new shell is started every time the script is invoked, and any settings such as set -f present in the invoking shell or in any other shell instance in the system are irrelevant.

Of course it's possible for users to source your script instead of running it, for instance like this:

. /path/to/your/script

or to execute it in a shell that has non-default settings like this:

sh -f /path/to/your/script

but those are not considered normal ways or invoking your script, and users who do that should expect whatever they get as a result.

Note that there are some scripts that are intended to be sourced, not executed, because their purpose is to to things such as changing the cwd or setting environment variables that must be reflected in the environment of the sourcing shell, but these are in the minority and it's usually done as part of an agreed protocol. These files can be considered more like "plugins" to whatever system they expect to be sourced by, not so much as independent scripts. For example, files in /etc/rc*.d with names that end in .sh are sourced by the startup script subsystem, not executed, and it is documented that this is what will happen if you place a file with such a name in /etc/rc*.d and when it's done it's done on purpose. The convention of naming files intended to be sourced instead of executed in this way is followed elsewhere too, but not universally.

It's true that files intended to be sourced in this way have to take care of what settings might be present in their caller's environment that might affect the behaviour of the shell, but then the agreed protocol should ideally promise a predictable execution environment.

Related Solutions

Bash – Run a command in an interactive shell with ssh after sourcing .bashrc

The problem is that you are trying to run an alias in a non-interactive shell. When you run ssh user@computer command, command is run non-interactively.

Non interactive shells don't read aliases (from man bash):

Aliases are not expanded when the shell is not interactive, unless the expand_aliases shell option is set using shopt (see the description of shopt under SHELL BUILTIN COMMANDS below).

It works if you run it again manually because the final bash command starts an interactive shell so your aliases are now available.

As an alternative, you could launch an interactive shell (bash -i) instead of a simple login shell (bash -l) on the remote machine to run your alias:

ssh user@remote_computer -t 'bash -ic "my_alias;bash"'

This seems a very complicated approach though. You haven't explained why exactly you need to do this but consider these alternatives:

Just start a normal login interactive shell on the remote machine and run the command manually:
```
user@local $ ssh user@remote
user@remote $ my_alias
```
If you always want that alias to be run when you connect to this computer, edit the ~/.profile (or ~/.bash_profile, if present) of the remote computer and add this line at the end:
```
my_alias
```
Because ~/.profile is read each time a login shell is started (so, each time you connect via ssh, for example), that will cause my_alias to be run each time you connect.

Note that by default, login shells read ~/.profile or ~/.bash_profile and ignore ~/.bashrc. Some distributions (Debian and its derivatives and Arch, for example) distributions like Ubuntu have their default ~/.profile or ~/.bash_profile files source ~/.bashrc which means that your aliases defined in ~/.bashrc will also be available in a login shell. This isn't true for all distributions, so you might have to edit your ~/.profile manually to have it source ~/.bashrc. Also note that if ~/.bash_profile exists, ~/.profile will be ignored by bash.

Bash – Are all the shell options not inherited by scripts

In the case of bash, that depends on whether $SHELLOPTS is in the environment or not.

bash-4.4$ export SHELLOPTS
bash-4.4$ set -x
bash-4.4$ bash -c 'echo x'
+ bash -c 'echo x'
+ echo x
x

See how the bash -c 'echo x' inherited the xtrace option. For the options set by shopt, it's the same but with the $BASHOPTS variable.

It comes handy especially for the xtrace option for debugging when you want to run a bash script (or any command running a bash script) and all other bash script it may invoke, recursively with xtrace (provided nothing does a set +x in those scripts). If your sh is bash, that will also affect them, so also the system("command line") made in other languages:

env SHELLOPTS=xtrace some-command

Best Answer

Related Solutions

Bash – Run a command in an interactive shell with ssh after sourcing .bashrc

Bash – Are all the shell options not inherited by scripts

Related Question