The way to answer that question is to try it:
1063 > batch
warning: commands will be executed using /bin/sh
at> env > /tmp/xxx
at> <EOT>
job 2 at 2000-12-09 21:57
1064 >
What you will see is that you will go through the entire login process for
that user. Your env will end up being exactly what it is when you log in.
--
-Time flies like the wind. Fruit flies like a banana. Stranger things have -
-happened but none stranger than this. Does your driver's license say Organ
-Donor?Black holes are where God divided by zero. Listen to me! We are all-
-individuals! What if this weren't a hypothetical question? [EMAIL PROTECTED]
On 9 Dec 2000, Harry Putnam wrote:
=>
=>[Note: Getting this thread back on track. It was derailed by my
=>subjectless post.... sorry ... having some email troubles here]
=>
=>"Brad Doster" <[EMAIL PROTECTED]> writes:
=>
=>> Thanks, Harry. For the time being, I've incorporated the pieces that define
=>> the variables in the scripts run by cron. It seems there ought to be a way
=>> to make defined variables globally available though, and I haven't been able
=>> to find out how -- I suppose the 'global availability' is really the crux of
=>> my question -- is it possible, and if so, can anyone help me get it to work?
=>
=>I couldn't find a refernce in the three related man pages, crond,
=>crontab(1) and crontab(2). But I seem to recall someone telling me
=>once that cron starts with a limited shell, some of the limitations
=>being $PATH and $ENV
=>
=>I'm definitely not an authority on this, so some of the sharp shooter
=>here will probably know. Making crontab extact whatever VARS you want
=>from the global environment can be done in the way I described.
=>
=>> As for your script enhancements, I'll have to look at the man pages to see
=>> what you've done <g>.
=>
=>Its no great improvement, just makes fewer system calls.
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
