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.
gpg's--batchoption instead. What is your end goal? – Chris Down Sep 17 '11 at 11:07~/.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