LinuxQuestions.org
Did you know LQ has a Linux Hardware Compatibility List?
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - General
User Name
Password
Linux - General This Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.

Notices

Reply
 
Search this Thread
Old 04-05-2009, 11:52 AM   #1
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0/14.1
Posts: 3,479

Rep: Reputation: 533Reputation: 533Reputation: 533Reputation: 533Reputation: 533Reputation: 533
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.
 
Old 04-05-2009, 04:13 PM   #2
Tinkster
Moderator
 
Registered: Apr 2002
Location: in a fallen world
Distribution: slackware by choice, others too :} ... android.
Posts: 22,966
Blog Entries: 11

Rep: Reputation: 865Reputation: 865Reputation: 865Reputation: 865Reputation: 865Reputation: 865Reputation: 865
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
 
Old 04-05-2009, 05:04 PM   #3
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0/14.1
Posts: 3,479

Original Poster
Rep: Reputation: 533Reputation: 533Reputation: 533Reputation: 533Reputation: 533Reputation: 533
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.
 
Old 04-05-2009, 05:31 PM   #4
Tinkster
Moderator
 
Registered: Apr 2002
Location: in a fallen world
Distribution: slackware by choice, others too :} ... android.
Posts: 22,966
Blog Entries: 11

Rep: Reputation: 865Reputation: 865Reputation: 865Reputation: 865Reputation: 865Reputation: 865Reputation: 865
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
 
Old 04-05-2009, 06:36 PM   #5
i92guboj
Gentoo support team
 
Registered: May 2008
Location: Lucena, Córdoba (Spain)
Distribution: Gentoo
Posts: 4,036

Rep: Reputation: 372Reputation: 372Reputation: 372Reputation: 372
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.
 
Old 04-05-2009, 08:16 PM   #6
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0/14.1
Posts: 3,479

Original Poster
Rep: Reputation: 533Reputation: 533Reputation: 533Reputation: 533Reputation: 533Reputation: 533
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.
 
Old 04-05-2009, 08:22 PM   #7
i92guboj
Gentoo support team
 
Registered: May 2008
Location: Lucena, Córdoba (Spain)
Distribution: Gentoo
Posts: 4,036

Rep: Reputation: 372Reputation: 372Reputation: 372Reputation: 372
Quote:
Originally Posted by Woodsman View Post
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.
You need to set the DISPLAY variable, you can try yourself with this command and it should work:

Code:
DISPLAY=:0.0 kdialog whatever_else
How to determine the available displays and which one to use is another thing
 
Old 04-05-2009, 08:34 PM   #8
Tinkster
Moderator
 
Registered: Apr 2002
Location: in a fallen world
Distribution: slackware by choice, others too :} ... android.
Posts: 22,966
Blog Entries: 11

Rep: Reputation: 865Reputation: 865Reputation: 865Reputation: 865Reputation: 865Reputation: 865Reputation: 865
Quote:
Originally Posted by i92guboj View Post
You need to set the DISPLAY variable, you can try yourself with this command and it should work:

Code:
DISPLAY=:0.0 kdialog whatever_else
How to determine the available displays and which one to use is another thing
That, or use something like gkrellm to monitor the e-Mails ;}
 
Old 04-06-2009, 02:15 PM   #9
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0/14.1
Posts: 3,479

Original Poster
Rep: Reputation: 533Reputation: 533Reputation: 533Reputation: 533Reputation: 533Reputation: 533
Quote:
How to determine the available displays and which one to use is another thing
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Environment variables xeon123 Linux - General 6 05-18-2007 07:57 PM
Environment variables rumi2 Linux - Newbie 2 01-17-2007 06:44 PM
environment variables user_linux Linux - Newbie 3 06-15-2005 08:46 AM
environment variables kakridge Linux - Newbie 1 07-14-2003 06:25 PM
Environment variables kdnt Linux - Newbie 11 11-01-2002 08:19 AM


All times are GMT -5. The time now is 11:32 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration