Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Both the shell and environment variables that cronjobs are run in is completely different from the ones presented to me in gnome-terminal. How can I run a cronjob under the same circumstances as if I had run it in the terminal?

My current solution is running the cronjob env DISPLAY=:0.0 gnome-terminal -e my-command, but this pops up a gnome-terminal, which isn't really acceptable.

share|improve this question
    
Define "regular environment". How should we determine what your "regular environment" is, if not simply the one inherited by a login shell? What is it particularly that you are looking for here? –  Chris Down Sep 17 '11 at 10:54
    
@Chris: The problem I'm actually trying to solve is that I can't use gpg-agent in my cronjob, which I think is because GPG_AGENT_INFO is undefined there. –  user4518 Sep 17 '11 at 11:05
    
If it's acceptable (I don't know if it is, because I don't know your end goal), you could also use gpg's --batch option instead. What is your end goal? –  Chris Down Sep 17 '11 at 11:07
    
@Chris: I want to sign and decrypt files as part of my daily backup, and I'm not comfortable putting the passphrase to my private key in the backup script. Thus, I'm hoping to use the cached passphrase from gpg-agent. –  user4518 Sep 17 '11 at 11:19
    
In which case, source ~/.gpg-agent-info, which is made for external programs to get information about the current agent. In future, you'd be better to ask the actual question instead of asking what you think we want to hear -- we can't help you effectively if you are not clear about your goal :-) –  Chris Down Sep 17 '11 at 11:27

2 Answers 2

up vote 2 down vote accepted

You can either explicitly specify the environment variables you want at the top of your crontab, or you can source your environment from somewhere.

To add environment variables explicitly, you can use a line like this at the top of your script (after the hashbang):

FOO=bar

To source them from a file, use a line like this:

. /foo/bar/baz

In response to your edit of your question to include gpg-agent, you should be able to source ~/.gpg-agent-info to get $GPG_AGENT_INFO. If it does not exist, try starting gpg-agent with --write-env-file "${HOME}/.gpg-agent-info".

share|improve this answer
    
This would work for specific environment variables. I'd want all of them to be the same. –  user4518 Sep 17 '11 at 10:36
1  
Then source your environment. The files you probably want to source are /etc/profile, and your profile in your local directory (will vary between shells, for bash its ~/.bash_profile). This will give it the same starting environment as a login shell. –  Chris Down Sep 17 '11 at 10:39
    
Thanks for the suggestion. I grepped through /etc looking for the initialisation of gpg-agent, and it's in /etc/X11/Xsession.d/60seahorse-plugins. I'm a bit afraid to edit such a file, so if there's another solution (e.g. somehow reading the other environment's GPG_AGENT_INFO), I'd prefer that! –  user4518 Sep 17 '11 at 12:17
    
There's nothing to be afraid of. --write-env-file "${HOME}/.gpg-agent-info" shouldn't screw anything else up. Before you edit it, just make a backup (with cp /etc/X11/Xsession.d/60seahorse-plugins ~/), and then if something goes wrong (it shouldn't), you can just restore it from your home dir (don't back up to the same directory, or the backup will still be executed). –  Chris Down Sep 17 '11 at 12:21
    
Thank you very much for your help! –  user4518 Sep 17 '11 at 13:00

You are correct that processes should not be able to peek in on other process environments. This is very much by design. But, export will neatly package your environment to be picked up by something else.

What you can do is something like this in your .bashrc:

[[ $DISPLAY ]] && export > ~/.cron_bread_crumbs/gonme_env

Then have your cron job simply pick it up.

. /home/user/.cron_bread_crumbs/gnome_env

The file will be full of lines like this:

declare -x ENV_VARIABLE="value"

Values will, of course, be quoted. That's what I meant by saying 'packaged neatly'.

Sourcing this (thereby calling declare -x which is an export) means all subsequent processes that start (and perhaps detach) from the parent cron will also inherit these values.

This is a little kludgy, though, because it assumes that you've popped open one gnome terminal causing the values to be refreshed prior to the cron running. A little sanity in the cron job shouldn't be too difficult to add, however.

Your other option is to start something in the background that just blocks while dumping the environment to a named pipe, then let the cron job pick it up from there. Either way, the kludge lies in making sure something happens via Gnome terminal so the cron job gets the variables.

share|improve this answer
1  
If your intent in using [ $TERM -eq "xterm" ] is to check if the shell is being run in a graphical environment, something like [[ $DISPLAY ]] && export > ~/.cron_bread_crumbs/gonme_env would possibly be more suited (for example, it wouldn't work for me, since my $TERM is st-256color). –  Chris Down Sep 17 '11 at 12:03
    
@ChrisDown Yes, good suggestion. I was thinking in the context of the OP's environment. Editing. –  Tim Post Sep 17 '11 at 12:09
    
Note that you may need to put SHELL=/bin/bash in the crontab, if your system has a different shell as /bin/sh (what bash's export built-in prints out isn't readable in other shells, and what ash). Alternatively, use the export command in a different shell such as ash. Don't use the env utility, because its output is not quoted properly. And this environment copying may have undesired consequences, such as making the cron job believe an X display or Screen session is available when none is. –  Gilles Sep 17 '11 at 20:58

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.