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. |
Quote:
Code:
DISPLAY=:0.0 kdialog whatever_else |
Quote:
|
Quote:
|
All times are GMT -5. The time now is 12:07 AM. |