So I read Furlani et al's papers on "Modules".
Modules is not so bad - it is a nice way of dealing with an annoying problem.
Or, rather, Modules may be the best possible way of dealing with environment dependent code. But it might be better to discourage environment dependent code in the first place. See my earlier post about environment dependent code being a dominant meme.
--
Minor observation: I would like to bring some non-Modules source scripts "kicking and screaming into the '90s with Modules". I would like to simply wrapperize some existing legacy code that requires you to "set some environment variables and then source foo". I.re.I don't want to rewrite foo - I would just like to wrap it in a module.
Modules does not seem to be able to do this.
Although it looks as if it would only be a minor extension to modules to handle it.
Subscribe to:
Post Comments (Atom)
3 comments:
"Minor extension" in terms of saving the environment, running the script, checking for all differences, and hoping nothing happened outside the environment?
I just converted Intel's compilers and tools scripts to modules. The above approach would have sufficed.
I can't tell if the poster is agreeing with me, or disagreeing and saying that modules is the best thing since sliced bread. Or both.
Myself, I have recently started used Expect (actually Perl's Expect.pm module, with a lot of my own stuff around) to automate stuff that relies on setting environment variables and other side effects. Modules stuff, but also quite a bit of stuff that isn't modules, i.e. which is even less well behaved than modules.
(I repeat: modules may be the best of a bad lot.)
I have had to deal with procedures or flows that contain multiple steps, each of which begins with "Start a new shell" "Or open a new window", or sometimes even "log out and log in again to get a fresh environment" (or ssh, or ...)
So I need a master script that invokes these subshells. Each of which loads and unloads modules, sources csh scripts and particular .login files, etc. Relying on environment variable side effects, aliases, and, heck, even chdirs inside these scripts.
And then throwing that all away, and restarting the next step with a new shell.
Expect is my friend. Rather than spending a lot of time that I don't have (automation is not my job, I just can't stand to use non-automated things, so I do automation to get my job done), I can just wrapperize these procedures and go.
Oh, yes: it would be easy, in my Expect scripts, to detect any environment variable changes done as a result of sourcing those csh files, and import those back into the outside script. Ditto chdir changes. The /proc filesystem is my friend.
One can imagine detecting filesysterm changes - ptrace? - but what is the point?
Ad one could create a module that wrapped around the Expect calls - i.e. which used Expect to import all of that stufrf ionto csh or bash.
But, y'know, I don't think I *want* to have a module import it into my running environment. I would rather just leave it encapsulated, and NOT pollute my interactive shell.
Modules are a structured way of managing the pollution in you7r environment.
Better to not pollute at all. Or to do the pollution in its own little life support system - a separate process or shell. That I currently automate via Expect.
If there is a better way to do that automation, please tell me.
Post a Comment