I recently came up to an easy fix for a crontab logging issue and I am wondering what are the pro's and con's of using this specific fix (running a script with a "login shell flag"), as:
#!/bin/bash -l
Asked
Active
Viewed 5,279 times
9
-
1I do wonder how being a login shell was even related to your issue there.. – ilkkachu Feb 07 '18 at 10:16
-
Sorry ikkachu, I cannot remember what this was about precisely ! I found a better way for fixing my issue anyway. – Pier Feb 18 '18 at 17:26
2 Answers
13
[The following assumes that your unspecified "logging issue" was related to missing environment setup, normally inherited from your profile.]
The -l option tells bash to read all the various "profile" scripts, from /etc and from your home directory. Bash normally only does this for interactive sessions (in which bash is run without any command line parameters).
Normal scripts have no business reading the profile; they're supposed to run in the environment they were given. That said, you might want to do this for personal scripts, maybe, if they're tightly bound to your environment and you plan to run them outside of a normal session.
A crontab is one example of running a script outside your session, so yes, go do it!
If the script is purely for the use of the crontab then adding -l to the shebang is fine. If you might use the script other ways then consider fixing the environment problem in the crontab itself:
0 * * * * bash -l hourly.sh
ams
- 5,807
- 1
- 20
- 27
-
1Rather than relying on the way the script is invoked, one could also explicitly source the relevant shell files from within the script. This would additionally serve to (to a degree) document the fact that the script needs profile-specific setup. – Kusalananda Feb 07 '18 at 10:49
-
Thanks ams for your insight, that was some solution I did not think about. – Pier Feb 07 '18 at 11:41
-
Also, if the user is doing something like this, there will be trouble. – Kusalananda Feb 08 '18 at 20:25
0
I honestly don't see any benefit of running a non-interactive script in a login shell.
The login shell will parse the relevant login shell initialization files (bash uses ~/.bash_profile) to set up the shell session's environment etc.
It is not unreasonable to believe that a user may do all sorts of interesting things in this file, such as starting tmux (like in this question) or even running exec on another shell altogether (as in this question, and this).
Instead, the environment that the script needs to run in should be set up in the file pointed to by $BASH_ENV. This file will be sourced by any non-interactive bash shell.
A script being run from a cron job would not be run in an interactive shell nor in a login shell, and it would then need to be started as
@daily BASH_ENV="$HOME/script.env" "$HOME/script.sh"
(for a daily job triggered at midnight) here $HOME/script.env may be $HOME/.bashrc if that's where the environment is set up.
Kusalananda
- 333,661