Geek pop quiz:

[theweaselking]

Is there an easy way to tell where a Linux environment variable is set? Like, which config file it was in, when you've got an incestuously complicated set of sub-references and called files, and the normal "new user" script involves pulling in the entire bunch?

(Oh, and there's roughly 20TB of teeny little files where this COULD be set. So "grep -r VARIABLE=VALUE /*" will take months.)

.bashrc calls three other scripts, each of which call other scripts in turn, and it all works out... in practice. But we can't seem to find out WHERE one specific environment variable gets set.

EDIT: Brute force FTW. Comment out each line in turn until the variable stops being set. Follow that file. Repeat.

Only took about 30 minutes, versus grep.

EDIT2: Oh, and if I *had* run that grep command, that would have totally sucked for me when, in October, I got my results and it had no useful lines in it - because "/*" will ignore hidden files. I more wanted "/.*", or maybe even "/\.*". The second is less thorough but would have worked since it *was*, finally, set in a .file.

Comments

[catsidhe.livejournal.com]

Short of writing a script to read, parse, and walk backwards through referred files, not that I know of, no.

HTH, HAND.

[nsanity-au.livejournal.com]

on windows maybe do a filemon and a trace.

I dare say you could do this with a programming IDE reasonably easily.

[theweaselking.livejournal.com]

Yes, but I have bash and grep.

[nsanity-au.livejournal.com]

and 20TB :)

I assume you want to change the value of it, and have tried just updating the variable again where you do have control?

I know its messy, but really the best way of dealing with this is letting a software dev have a go imo.

[theweaselking.livejournal.com]

I assume you want to change the value of it, and have tried just updating the variable again where you do have control?

Why yes! That works just fine!

The problem is this: Changing which project you're working on sets a pile of environment variables, using a project-specific script. This is all done with a simple script, "local projectname", which runs the project-specific script *and* a bunch of other cleanup things and makes sure everything is set right.

One project needs this variable to change. The problem is, while the project-specific script (project.sh) sets the variable and it works if you run that manually, if you set the project the way you set ALL OTHER PROJECTS that variable is overridden in a place we couldn't find.

(and yes, this is much more information than the original post had. This is because I learned all this information while digging in to try to find the problem - the original problem description I got was... lacking.)

[nubule.livejournal.com]

I’m not that knowledgable in this area, but what if you aliased export and logged when and where variables were set? Maybe that wouldn’t work.

[mhoye.livejournal.com]

You can't alias a builtin.

[ydna.livejournal.com]

But you can make shell functions with the same name as a builtin. But in this case it won't matter.

[ydna.livejournal.com]

A shell function may be a better way to go. But, the variable may not have been set with export.

[mhoye.livejournal.com]

.bashrc, .profile and the rest of the usual suspects are for users. Environment variables for services are set in their init scripts, usually under /etc/init.d/* or /etc/sysconfig/somethingorother. But in these modern times, it really could be anywhere.

[theweaselking.livejournal.com]

Yeah, "really anywhere" about sums it up. But a little cleverness in *how* to brute-force the problem produced a ~30min 2-person brute-force solution that worked.

[corruptedjasper.livejournal.com]

Surely given a modern computer (with an SSD root) grepping through /etc won't take so terribly long!

[theweaselking.livejournal.com]

On a computer with a teeny and extremely fast drive, that would be true.

This is a computer with a monstrously huge 20TB "drive" on a NAS. And the files in question are definitely not in /etc/, because that's local and the files are not stored locally per-machine.

[secretagentmoof]

for future reference: zsh has $PS4, which is used with `zsh -x script`; you can set all sorts of interesting things in there, but by default, you get something like this:

pf dogcow@veal: ~/bin 3266 % zsh -x /etc/rc |& head
+/home/dogcow/.zshenv:4> export 'CVS_RSH=ssh'
+/home/dogcow/.zshenv:6> [ -n 78592.ttyp2.veal ']'
+/home/dogcow/.zshenv:12> export 'FTP_PASSIVE=1'
+/home/dogcow/.zshenv:14> [ -n '' ']'
+/etc/rc:41> stty status '^T'
+/etc/rc:46> trap : 2
+/etc/rc:47> trap 'echo '\''Boot interrupted'\''; exit 1' 3


Re: EDIT2

[rbarclay.livejournal.com]

Wonders of GNU grep and -r:

~ $ echo foo >/tmp/w/.bar
~ $ echo foo >/tmp/w/baz 
~ $ grep -r foo /tmp/w/*
foo
~ $ grep -r foo /tmp/w/ 
/tmp/w/baz:foo
/tmp/w/.bar:foo

Re: EDIT2

[theweaselking.livejournal.com]

Hah! Good to know.