I have several questions related to non-interactive, non-login shells and cron jobs.
Q1. I have read that non-interactive, non-login shells only "load" $BASH_ENV
.
What does this exactly mean? Does it mean that I can point $BASH_ENV
to a file, and that this file will be sourced?
Q2: Assuming that I have an entry in cron
pointing to a Bash script with a Bash shebang, what environment variables and definitions can I assume my Bash script is loaded with?
Q3: If I add SHELL=/bin/bash
to the top of my crontab
, what exactly does this do? Does it mean that:
cron
itself runs in Bash?- The commands specified in
crontab
are interpreted in Bash? - The scripts that do not have
shebangs
in them, are run under$SHELL
something else?
Q4: How can I set BASH_ENV
for cron jobs?
Best Answer
For Q1 & Q2, see here. Q3 is answered in the discussion of your other three questions below.
WRT
$BASH_ENV
, fromman bash
:So this could be a
.profile
type script. As to where or who set it, this depends on context -- generally it is not set, but it could have been by any ancestor of the current process.cron
does not seem to make any special use of this, and AFAIK neither does init.If by "in" you mean, is started from a shell, then this depends on the init system -- e.g., SysV executes shell scripts for services, so those services are always started via a shell.
But if by "in" you mean, "Is it thus a child of a shell process?", no. Like other daemons it runs as the leader of its own process group and its parent process is the init process (pid 1).
The consequences for
cron
's environment are probably immaterial, however. For more about the environment of start-up services, see the answer linked above regarding Q1 & Q2. WRT to cron specifically, according toman 5 crontab
it also sets some environment variables that are inherited by any process it starts ($LOGNAME
,$HOME
, and$SHELL
).They're interpreted with
sh
or$SHELL
; again fromman 5 crontab
:The emphasized part anwsers Q3.
Executable scripts with or without shebangs are opened by
$SHELL
(orsh
). The difference is, those with a shebang will then be handed to the appropriate interpreter (#!/bin/sh
being another instance of the shell), whereas executable scripts (ones with the executable bit set that are reference as executables) without a shebang will simply fail, just as they would when run from the command line (unless you run themsh script.sh
).