Environment Variables and the At Command
 

Is there a way to either stop the at command from inheriting environment variables? If not, is there a way at run-time to force a job to grab the actual environment variables and ignore the inherited variables?

I want a script I schedule with the at command to test for a certain environment variable ($KDE_SESSION_UID) at the time the script executes. The test programmatically determines how the script sends text messages to me (using stdout or kdialog).

Problem: The at command inherits the current environment variables (except the TERM, DISPLAY, and '_' variables). Users can verify this by typing at -c {job}. Makes sense but not what I want because the inherited environment is what the script sees at run-time rather than the actual environment variables I am trying to test.

Of course, the environment variables are different from within a terminal window inside X and a terminal outside of X.

For example, if at 10:05 AM I type:

echo '/name/of/script' | at 23:11

At 23:11, the script will see the environment variables captured by the at command at 10:05 rather than the actual environment variables present at 23:11.

These are always one-time executions, therefore cron is not an option. :)

I'm using Slackware 12.2, with KDE 3.5.10 and at 3.1.9.

Thanks again. :)

I'm confused as to what your problem would be. Neither of TERM,
DISPLAY, and '_' are equal to KDE_SESSION_UID, which *SHOULD*
be set ats time of invocation (if you happen to invoke at from within
a KDE environment).



Cheers,
Tink

Okay, let me rephrase. :)

I have the script check for the existence of $KDE_SESSION_UID. Usually I run the script when logged off and not in X. In that case, the $KDE_SESSION_UID does not exist. The script then send any messages to stdout. That works because at sends me an email and I see the messages there.

When I am in X/KDE and the script executes, I have the script send me the same messages but through kdialog.

Because at inherits the environment variables when invoked rather than when executed, and usually I run the echo ... | at command from within Konsole, the $KDE_SESSION_UID exists. The script executes later and sees the variable from the inherited environment rather than the current or existing environment, regardless of whether I am logged in or running X. I then receive error messages in the resulting email that kdialog cannot run because X is not running. Livable but not clean or "professional."

I can't test for the $DISPLAY variable because at does not capture that variable. Would not work anyway because of the way at inherits the environment variables.

I can run the echo ... | at command from a non-X console. That is a workaround solution, but does not solve the problem of determining whether I am running the script while running KDE. I am looking for a programmatic solution. I can't find a way to disable or prevent at from inheriting the environment variables when scheduled. Therefore I suppose I have to find a way when my scripts launches to ignore the inherited variables and use some other test.

OK, gotcha.

Now, I don't use KDE, so am not certain what kind of processes to expect as
being run by which user, but I'd probably go down the route of
pgrep -l -u your_account
and see whether or not you're currently using a KDE session or not.




Cheers,
Tink

The problem is not with at, it's just the way that shells and environment works. A script can't reach the environment of a completely unrelated process.

You could check if X is running (kdialog doesn't necessarily require that you are in kde to be able to run), as Tinkster said above. However, that doesn't necessarily mean that you have X on the current VT, you could have X on VT7 while you are working on console on VT1, also note that it doesn't mean either that you are logged in. You could have kdm active on VT7 while you work on VT1.

I am not sure how would I implement this myself.

The pgrep idea did help me determine whether the user account is currently logged on and ignores the inherited environment variable problem. Thanks.

However, with additional testing I discovered the real problem is getting kdialog to send a message. The command only succeeds when launched within a known X session. As the at job launches in a separate shell, there is no X session. Hence the error message.

The sole purpose of running a kdialog message in real-time was to alert me that the script encountered an error. The kdialog option in my script works great if I launch the script directly but not indirectly as with at.

The email I receive from at informs me of any errors but not in real-time. Therefore I need to discover a method to alert me in real-time if I happen to be logged on when the script executes as scheduled and encounters an error. Of course, I could be away from my computer, but some kind of alert would be better than nothing.

You need to set the DISPLAY variable, you can try yourself with this command and it should work:

How to determine the available displays and which one to use is another thing :p

That, or use something like gkrellm to monitor the e-Mails ;}

Indeed. :) Especially if X is started from a display manager. I can grep ps to determine whether the user has launched startkde, but that does not tell me which display the user is using because in run level 4, X is launched by root. In run level 3 X is launched by the user. Oh well.