How to call .profile in cron?

Hello all,

I want to call my users .profile in cron?

I understand that i have to do it explicitly in crontab entry.

How can we do it ? How can i write a simple script calling it?

Thanks & Regards
Abhijeet

. $HOME/.profile

-Mike

How is the .profile file comes into play when we run a scripts ?

It doesn't... the .profile is read only by a login shell, not every time a shell script is run.

When you login, since your .profile is read, you have certain things set up for you- like your $PATH. If those things are in environment variables (that is, if they've been exported), then scripts will have access to those things. Again, a good example is the $PATH. However, when cron runs a script the .profile is not read. This causes problems when you write scripts because things work when you run them but not when cron runs them.

So you need to always check your assumptions when doing shell programming... things like "What directory does the shell script think it's in?" and "What PATH does the shell script require?"
-Mike

Hi

Here is a line from my crontab:

10 4 * * * . ~/.profile; ${SCRIPTS}/backup_mysql.sh >> ${BACKUPS_LOG}/${HOSTNAME}_mysql_v${VERS}.script.log 2>&1

Assume each crontab command line generates a new shell. The ". ~/.profile;" command string: "dot space <...>", populates the environment variables for the new shell. The variables - in this case - are specific to the USER. They are called from the users home directory, etc.

The ". ~/.profile; " command string must be on the same crontab line, separated with ";" - a semi-colon. Do the same for EACH crontab command line.

Hope this is helpful!

Regards
GrahamB

For the scripts that I've written, I execute the .profile within the script - not in cron.

hence, in the script ${SCRIPTS}/backup_mysql.sh, you would see ...

#!/usr/bin/ksh
...
#- Ensure User Environment Set -#
. ${HOME}/.profile
...
[rest of script]

Hope that's of some help.

Caveat Programmer: . ~/.profile MAY work- for example, if you are in Linux, where sh is the same as bash. However, for Solaris and other UNICES, sh is the bourne shell and will not recognize the ~ (tilde) metacharacter.

For them, you must use

. $HOME/.profile

Thus, in general, it is better to use $HOME in cronjobs rather than getting used to a metacharacter which is peculiar to non-bourne shells.

Also, I would caution against using $HOME/.profile in any shell script, in any event. This is because the $HOME/.profile is for setting up your login profile. When you are running a script you are not logged in. Your scripting environment should be stable, secure, and knowable. Since my .profile is mine, it's liable to be messed with at any time. Also, if you're doing such things as database backups or some system-related function with your ID- or depending on resources affiliated with your ID- what happens when you leave your job?

Make a nice happy, stable home for your shell scripts. It's good style, and some SA will thank you for it later...
-Mike Schwager

Mike's suggestion is spot on.
I should have made some clarification with my post.
The example I provided was a script/s being executed by an effectively non-interactive user-id and not your own.
Hope that makes some sence.

HI,

I am lil bit confused here.... should we not use .profile in the script at all....I was in assumption that it is the safest way of doing it .....If we have our username and password in a script can't we use the variables defined in our .profile and use those variables in our script and run our .profile at starting of our script....I thought it is the best way...Is it not ...? please suggest if there is another way....

Thanks,

Girinath.

As an alternative to relying on any .profile file is to create work specific environment files and have them executed.

For example.

#!/usr/bin/ksh
#
#- Ensure User Environment Set -#
. ${PATHNAME}/proofing.env
...
[rest of script]
...
#-End-of-script-#

The idea here is similar to the use of a .profile, however the principle is the same. The big difference is that the exporting of the variables and their values is not done on each login (using .profile) and are instead invoked only from the scripts that you wish to use the particular environment file.

An example of what an environment file might contain ...

AU_GMT_OFFSET='10'
NZ_GMT_OFFSET='12'
ACCOUNTS_EML_ADD='<some_email@domain.com>'
ADMIN_EML_ADD='<some_email@domain.com>'

It is these variables that are referenced in the script.
Hope that's of some help.

I strongly discourage script to use the ${HOME}/.profile.
The ${HOME}/.profile is used for login and highly volatile to changes by users.

Imagine when you need to perform migration or the new application owner prefers to use a new shell or make changes to the .profile, unknowing it will impact the script.

Should always use a separate file for the script environment setting.

True - something already discussed in this thread.

See stty tcgetattr errors for another problem caused by .profile abuse.

Thanks for the link/article Perderabo - good read.

Gurus,
my problem is though not solved...

i want to run two scripts daily via cron.
i run them manually & they work..but when i put them in cron ,they don work..
thats where the idea of calling .profile in cron came to my mind.
i tried two ways : 1> $HOME./profile 2> . .profile

both have not worked.

how should i set the cron enviroment so that these scripts run?

this concept is quite confusing to me ;bcoz i had put ". .profile" in one of my scripts on other prod server & it worked there ( in cron ).

I need help/advice on doing it.I am running short of time.

Thanks & Regards
Abhijeet

The posts above tell you everything you need to know (plus you've answered your own question with the example of the script that works when called by the cron).

Your .profile contains environment variables that are needed for the script to work. You can call .profile from within your scripts but, as has been pointed out, for safety you should create a separate environment file containing the neccessary environment settings and call that from within the scripts instead.