Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

who exported this variable?

90 views
Skip to first unread message

Nikhil

unread,
Aug 12, 2005, 3:41:02 PM8/12/05
to
Hi Folks...

I have a question which has been tickling my mind from many days...

In an UNIX Shell..,we know that there are shell variables exported,but
can we get to know if that shell variable is exported by which program
or which rcfile.

Basically the issue appears something like this...
I have my login shell as tcsh
and I have my .cshrc, .login, .pathrc, .envrc files in home directory(
though its different that I do not remember exactly the sequence in
which they are ordered or executed). and these rc files do some
enviroment variables set in.
at shell prompt, when I press '$' and followed by <TAB>, I see a whole
lot of shell variables trolling on the screen...but now the question is
from whereon these (or one of these) variables have been sourced or
exported from or which rc file was read to set this (or these) env
variable(s)?

Please forgive me if the question does not stand to its validness..and
can any one please convince me.

Regards,
Nikhil

Michael Tosch

unread,
Aug 12, 2005, 5:58:45 PM8/12/05
to

Tracking the processes' environment is possible.
Unfortunately the tools are, if available at all, platform-specific.

On Solaris the parent processes of the current shell are shown by
ptree $$

and the environment of a process is shown by
/usr/ucb/ps eww <pid>

Combined in a script:

envtrace(){
ptree $$ |
while read pid prog
do
/usr/ucb/ps eww $pid
done |
sed -n '
s/^ *//
/^[^0-9]/d
h
s/ .*/:/p
g
s/^.* \('"$1"'=[^ ]*\).*/\1/p
g
/^'"$$"' /q'
}

envtrace PATH
envtrace OSTYPE

shows you where PATH and OSTYPE come from.

As I said, this is Solaris-specific.
I think that Perl and even C is better portable here
=> Newsgroups comp.lang.perl

To track the login scripts, read the man page for
your login shell:

man `basename $SHELL`

and apply a "human parser".


--
Michael Tosch @ hp : com

Robert Bonomi

unread,
Aug 12, 2005, 7:09:03 PM8/12/05
to
In article <1123875662.9...@g49g2000cwa.googlegroups.com>,


'exported' variables are passed into child processes, so, by examining
the environment of parent processes all the way back to 'init', one can
tell which "level" of process the variable was set in.

*HOWEVER*, there is no readily accessible record of what 'sourced' script
created that particular environment variable, or even whether or not it
was set interactively from the shell prompt. You -may- be able to get
some "glimmer" of the culprit, if you have access to the command and process
accounting system logs .

Special case: If you're running on a 'secure' system -- one that meets U.S.
DOD/NSA requirements for handling classified (at a level above 'confidential',
that is) data -- the security audit logs would have the requisite information.
Now, whether or not *you* can get access to those audit logs, that is an
=entirely= different question! *grin*

Barry Margolin

unread,
Aug 12, 2005, 8:34:04 PM8/12/05
to

> Hi Folks...
>
> I have a question which has been tickling my mind from many days...
>
> In an UNIX Shell..,we know that there are shell variables exported,but
> can we get to know if that shell variable is exported by which program
> or which rcfile.
>
> Basically the issue appears something like this...
> I have my login shell as tcsh
> and I have my .cshrc, .login, .pathrc, .envrc files in home directory(
> though its different that I do not remember exactly the sequence in
> which they are ordered or executed). and these rc files do some
> enviroment variables set in.
> at shell prompt, when I press '$' and followed by <TAB>, I see a whole
> lot of shell variables trolling on the screen...but now the question is
> from whereon these (or one of these) variables have been sourced or
> exported from or which rc file was read to set this (or these) env
> variable(s)?

When you login, .cshrc is executed, and then .login is executed.
.pathrc and .envrc are not executed automatically by tcsh, there must be
commands in the other scripts that execute them.

Anyway, what you can do is put the following at the beginning of each
script:

echo ENTERING XXXX
set verbose

where XXXX is the name of that script, and the following at the end:

echo EXITING XXXX

The "set verbose" command causes the shell to display all the commands
as they're executed, so you can see when any particular variable is set,
and the ENTERING/EXITING lines will let you know which script did it.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Bruce Barnett

unread,
Aug 12, 2005, 9:04:58 PM8/12/05
to
Michael Tosch <eed...@NO.eed.SPAM.ericsson.PLS.se> writes:

> To track the login scripts, read the man page for
> your login shell:

Here is another suggestion that may help. I used this to figure out
why things didn't work the way I expected.

For instance, I sometimes uncomment the first line in my .cshrc file:

#echo .cshrc: pid $$ user $?USER prompt $?prompt term $?term

and my .login file

#echo .login term: $term tty: `tty`

Some systems read a Bourne shell file (or files) even before starting
up the C shell. Others read files just for certain shells. some of
the files might be

/etc/profile
/etc/login
/etc/cshrc
/etc/profile.d/*

If you are root, you can modify these files as well to trace execution.

Since you mentioned tcsh, .cshrc is generally read first, and if it's
a login shell, then .login is read next.

If it's a new window, just .cshrc is read.

Also the command
set echo
set verbose
can be used to trace what happens.

I suggest you add these lines near the top of your .cshrc file to see
what happens.

#Top of .cshrc file---------------
echo .cshrc: pid $$ user $?USER prompt $?prompt term $?term
if ( ! ( $?USER && $?prompt && $?TERM )) exit
set echo
set verbose

The exit command is used to make sure the echo/verbose flags are only set
in interactive shells run on the local machine.


--
Sending unsolicited commercial e-mail to this account incurs a fee of
$500 per message, and acknowledges the legality of this contract.

Nikhil

unread,
Aug 14, 2005, 5:25:31 AM8/14/05
to
Thanks for the reply, Michael..I could get what you said.
But is not it really possible if one could tell where the OSTYPE or
PATH variable have been really defined, or in specific where in which
(rc) file, these have been defined their values..

from the above function which you gave can tell us if the variable was
defined in the parent processes (or not ) and there on makes us to
search more... Right?

and moreever from the above points, we should be able to decipher
something like this.....
1)what are all the rc files where referred from the parent process to
the current process?
2) and search for a specific variable in those files, if the variable
was found in that file and indeed the file was read by the process and
3)morever the variable value in the rc/script file should match the
current value in the process and if not proceed to next rcfile which
was read,

then we should be able to say that the particular variable has been
defined in this process from that rc/script file.

What do you say about the above ones?

Regards.

Nikhil

unread,
Aug 14, 2005, 5:28:54 AM8/14/05
to
from this a second question appears...
can we tell what are the files were read by the process before it
started to be fully functional, (though we can strace/truss them
manually, but is there anything which keeps track or log of what were
the files read by the process during its lifetime ?

John L

unread,
Aug 15, 2005, 7:40:20 AM8/15/05
to

"Nikhil" <mni...@gmail.com> wrote in message news:1124011734.7...@o13g2000cwo.googlegroups.com...

Not that I can think of, though it would be possible
on a system-specific basis to trace which files a process
reads. But how would you know, or even define, the point
when a process becomes "fully functional"?

--
John.


0 new messages