In addition, all my scripts in /etc/crontab file are started under user "martin". However /home/martin/.bash_profile(for login shell) and /home/martin/.bashrc(for non-logging shell) contain some variables which are ignored in case of cron job, but are used in case I log into machine over SSH or open new bash session. Why cron ignores those variables? Isn't cron simply executing "/usr/local/bin/bash my-script.sh" with permissions for user "martin"?

8 Answers
8

You can source the file you want at the top of the script or beginning of the job for the user that is executing the job. The "source" command is a built-in. You'd do the same thing if you made edits to those files to load the changes.

Different scripts fire depending on if the connection is a login shell (or not), an interactive shell (or not), or both.

If you want to make bashrc you'll need to make this change:

When Bash is started non-interactively, to run a shell script, for
example, it looks for the variable BASH_ENV in the environment,
expands its value if it appears there, and uses the expanded value as
the name of a file to read and execute. Bash behaves as if the
following command were executed:

if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi

but the value of the PATH variable is not used to search for the file name.

As noted above, if a non-interactive shell is invoked with the --login option, Bash attempts to read and execute commands from the login shell startup files.

this works well also for Acquia Cloud Scheduled jobs, which are basically cron jobs. You can do the same, like: SHELL=/bin/bash && source /home/YOUR_USER_NAME/.bash_profile && sh ....
– Alejandro MorenoJan 22 '19 at 17:58

The -l option makes bash a login shell. Thus, it will read the user's .bash_profile. It won't read the user's .bashrc unless it is explicitly sourced by .bash_profile. This is because non-interactive shells don't automatically read .bashrc. But you shouldn't need .bashrc for a cron job because .bashrc is for setting things useful for an interactive shell.

bash acts differently whether it is a shell or a normal programming language (like perl or python).

By design, the settings in ~/.bash_profile, ~/.bashrc, etc. are for users to set things when bash plays the role of a shell (login shell, interractive shell). Think about environment you have in a xterm (interactive shell) or in ssh sessions (login shell) or in consoles (login shell).

In other hand, bash is also a powerful progamming language –think about many scripts for managing services in systemd– which requires a different style of working. For example, when a developer is writing a system script or a bash program, he/she will not like to source the user's ~/.bash_profile automatically. It is a normal program, not a shell. A normal program (including bash programs) would naturally inherit settings from the current working evironement (shell), but not set them.

If we write a program for cron in bash –it just happens to be written in bash; in fact, we can write it in python or perl or any other progamming language– then we can have an option to sources bash's ~/.bash_profile (read: setting of user's shell, which just happens to be the same language of your programming language):

[ -f /home/user/.bash_profile ] && . /home/user/.bash_profile

However, what if that particular user do not use bash as his/her shell? He/she may use zsh, ksh, fish, etc. So, that practice would not really work when writing program for public use.

So, you can source ~/.bash_profile if you think that will work. But, here, it is not about whether we are able to source a file, it is about how things should works in the system: the design concept. In short: we should view bash as something having 2 roles: shell and progamming language. Then everything will be much easier to understand.

I had the same issue when executing a node application from cron which uses NVM , In order to make bash shell to read the .bashrc file from cron just envoke the bash command with interactive shell option `-l.