Bash – Command that may return error code in .bashrc

bashbashrc

I would like to set a variable inside .bashrc to be equal to the output of a command that may return an error code.

I do not know the implications of doing such a thing. Will everything else work correctly even if this command fails?

The code in .bashrc currently is simply:

export MYVAR=$(my_dubious_command 2>/dev/null)

Is it safe to do this?

Best Answer

As l0b0 said, it's unlikely that your .bashrc would be running with errexit set, but you could take care of that situation by testing:

case $SHELLOPTS in
  (*errexit*)   set +e;
                export MYVAR=$(my_dubious_command 2>/dev/null);
                set -e
                ;;
  (*)           export MYVAR=$(my_dubious_command 2>/dev/null)
                ;;
esac

The export command, as written, should return 0, in case any subsequent commands check $?; you are not providing any invalid options to it, the variable name is a valid one, and you are not exporting a non-existent function.

The case statement checks to see if errexit is set; if so, it temporarily turns it off in order to run my_dubious_command.

Related Solutions

Bash – Strange behaviour of uninitialized arrays and unset arrays

You can see the difference with declare -p:

unset foo
declare -a foo
declare -p foo
# prints declare -a foo='()'
foo=
declare -p foo
# prints declare -a foo='([0]="")'

If you want to initialize an empty array, the output of the first declare -p is a good hint on the best way to declare it:

declare -a array='()'

(The declare -a part is probably optional, a simple array=() should work just as well.)

If you want to test if an array has 0 elements, use numeric comparison on ${#array[@]}; don't try to do a test -z on the expansion as won't give the correct result in many cases.

Bash – Invoke subshell command with loaded rcfile

Don't use the SHELL environment variable in a script. That's the user's preferred interactive shell. You don't know anything about the syntax it supports. It could be tcsh, zsh, fish, rc, …

Don't load .bashrc from a script. The user is likely to put things that rely on bash being interactive and having a terminal; it might hang, or reconfigure your terminal, or hide your script's output, or any number of bad things. When you run bash -c …, .bashrc is not loaded, and that's by design.

If you need to check that PATH is sane, you can do it in Python, you don't need to invoke a shell for that. If by “the code has to be robust in face of poorly configured environments” you mean that your Python script should try to replicate the PATH of interactive shells even if it isn't started from one, then don't: you're far more likely to mess up in strange ways (and in particular to override an explicit setting from the user) than you're likely to help the user.

If your script is dropping the user into an interactive shell for some reason, then do run os.environ['SHELL'], falling back to pwd.getpwuid(os.geteuid()).pw_shell if the environment variable isn't set. This will run an interactive shell provided that your script is running in a terminal, you don't need to attempt to guess -i or other options which may or may not mean what you hope. If your script isn't running in a terminal then it has no business attempting to interact with the user and shouldn't start an interactive shell.

Best Answer

Related Solutions

Bash – Strange behaviour of uninitialized arrays and unset arrays

Bash – Invoke subshell command with loaded rcfile

Related Question