modules-interest — Discussion forum for modules usage.

Re: [Modules] general RC files question

[Harlan S. <Har...@pf...>]

OK, I just discovered that the ~/.modules file is part of the EXT stuff.

Time to do more reading...

H

Re: [Modules] general RC files question

[Harlan S. <Har...@pf...>]

OK, that why my idea would (mostly) work here and not work in general.

Here, folks do not have their RC files modules-aware, so I have to find
another solution.

I may just tell folks:

- Use our easy hack and you have no control, or
- install modules-aware shell RC files and use the full power of modules 

Thanks...

H (who wonders why his test at linking the two files did not loop forever...)
--
> > > > So I had a dream.
> > > >
> > > > Would it be a Bad Idea to:
> > > >
> > > >  ln ~/.modules ~/.modulesrc
> > > >
> > > > H
> > > 
> > > Well, one is supposed to be processed by tcl, the other is supposed to
> > > be processed by all shells. Does your shell grok tcl ;-) ?
> > 
> > No, but modules does not process the .modules file on a per-shell startup
> > basis, and the .modulesrc file is not recognized by the "module init*"
> > commands.
> > 
> > Who is expected to process the ~/.modules file?
> 
> The design of modules as I understand it is such that you "bootstrap"
> them into a shell by:
> 
> 1. defining module alias (for every shell, because aliases cannot be
>    inherited);
> 
> 2. defining some module-specific variables (MODULESHOME, MODULEPATH,
>    MODULE_VERSION, MODULE_VERSION_STACK). That can be done in login
>    shell only and inherited;
> 
> 3. sourcing ~/.modules file for your initial shell-neutral setup. That
>    can be done in login shell only (if you're only setting up
>    environment variables).
> 
> Now, ~/.modulesrc is used every time you invoke modulecmd, so putting
> "module load" in there has a potential risk sending modulecmd into a
> loop, doesn't it?
> 
> Gintas

Re: [Modules] general RC files question

[Gintautas G. <gi...@ki...>]

> > > So I had a dream.
> > >
> > > Would it be a Bad Idea to:
> > >
> > >  ln ~/.modules ~/.modulesrc
> > >
> > > H
> > 
> > Well, one is supposed to be processed by tcl, the other is supposed to
> > be processed by all shells. Does your shell grok tcl ;-) ?
> 
> No, but modules does not process the .modules file on a per-shell startup
> basis, and the .modulesrc file is not recognized by the "module init*"
> commands.
> 
> Who is expected to process the ~/.modules file?

The design of modules as I understand it is such that you "bootstrap"
them into a shell by:

1. defining module alias (for every shell, because aliases cannot be
   inherited);

2. defining some module-specific variables (MODULESHOME, MODULEPATH,
   MODULE_VERSION, MODULE_VERSION_STACK). That can be done in login
   shell only and inherited;

3. sourcing ~/.modules file for your initial shell-neutral setup. That
   can be done in login shell only (if you're only setting up
   environment variables).

Now, ~/.modulesrc is used every time you invoke modulecmd, so putting
"module load" in there has a potential risk sending modulecmd into a
loop, doesn't it?

Gintas

Re: [Modules] general RC files question

[Harlan S. <Har...@pf...>]

> > So I had a dream.
> >
> > Would it be a Bad Idea to:
> >
> >  ln ~/.modules ~/.modulesrc
> >
> > H
> 
> Well, one is supposed to be processed by tcl, the other is supposed to
> be processed by all shells. Does your shell grok tcl ;-) ?

No, but modules does not process the .modules file on a per-shell startup
basis, and the .modulesrc file is not recognized by the "module init*"
commands.

Who is expected to process the ~/.modules file?

H

Re: [Modules] general RC files question

[Gintautas G. <gi...@ki...>]

> So I had a dream.
>
> Would it be a Bad Idea to:
>
>  ln ~/.modules ~/.modulesrc
>
> H

Well, one is supposed to be processed by tcl, the other is supposed to
be processed by all shells. Does your shell grok tcl ;-) ?

Gintas

Re: [Modules] general RC files question

[Harlan S. <Har...@pf...>]

So I had a dream.

Would it be a Bad Idea to:

 ln ~/.modules ~/.modulesrc

H

Re: [Modules] general RC files question

[Harlan S. <Har...@pf...>]

Is my previous message why I want something like a "module exist modulefile"
command?

Even that seems inadequate - there can be many .modules files along the
path.

Is the trick to put a .modulerc file every place there is a .modules file
and handle the inclusion that way?

I'm wondering about this - if there are multiple occurences of these files
along the path, how should one go about "invoking" the correct one?

H

[Modules] general RC files question

[Harlan S. <Har...@pf...>]

So I'm trying to convert the users of a large project to modules (config
management of the build toolchain).

There are most of the usual shells involved.

There are people who use wildly different RC files for each of these shells.

The manager does not want to ask people to change their RC files.

He suggested that since we do require people to source a $SHELL-specific
file already, we simply add the module init code to those files and
(hopefully) transparently solve the "cutover" problem.

The problem I'm having is that while our additions give people the right
environment for building the code, people now want to use modules to make
sure they get, for example, the same version of emacs on all platforms.
This is, of course, easy with modules.

The tricky part is that their normal RC files don't know *anything* about
modules, and we would prefer to keep it that way.

I was hoping I could simply give these folks a ~/.modules file that would be
the place where they put their customizations.

The good news is that the "module init*" commands see the ~?.modules file
and DTRT there.

The bad news is that apparently this file is not processed!

Any thoughts on how I can solve this problem?

H

[Modules] ~/.modules file?

[Harlan S. <Har...@pf...>]

So I read the code and decided that ~/.modules was probably the best place
to put shell-independent modules initload stuff.

I notice that "modules initlist" show any "load"ed modules from that file
first (or at least before the shell-specific RC files), and "module initadd"
will put the requested modulefiles in .modules .

However, I have also noticed that when I spawn a new shell (xterm, whatever)
that the commands in the .modules file do not get processed.  More
specifically, the things I ask to be loaded do not get loaded.

Any ideas?

H

[Modules] Re: Order of items in "module list"

[Ted S. <ste...@cr...>]

On Tue, 22 Oct 2002, Harlan Stenn wrote:
> Does the order in which modulefiles are displayed by "module list" have
> anything to do with load order?
> 
> I ask because I have put "module load" commands in specific order in certain
> "master" modulefiles, and I notice that the order in which these modulefiles
> is displayed by by "module list" is real different.
> 
> Bug or feature?

Hi Harlan,

According to what I have seen, which may not match your experience ...

If you are loading in an environment with no modules previously loaded, and
each module loads only itself (and not a bunch of others), then yes, the list
order is the same as the load order.

If you have a module already loaded, and then you load it again, its order
doesn't change.

If one module loads a bunch of others, module list shows those first and then
the wrapper module last.

What happens if you do "module purge" and/or "module clear" before your module
load command?

Ted
-- 
 Ted Stern                           Engineering Applications
 Cray Inc.                                http://www.cray.com
 411 First Avenue South, Suite 600               206-701-2182
 Seattle, WA 98104-2860                     FAX: 206-701-2500
 Debuggers' motto:  Frango ut patefaciam -- I break in order to reveal

Re: [Modules] Order of items in "module list"

[David C. M. <dav...@ba...>]

Harlan Stenn wrote:

>Does the order in which modulefiles are displayed by "module list" have
>anything to do with load order?
>
>I ask because I have put "module load" commands in specific order in certain
>"master" modulefiles, and I notice that the order in which these modulefiles
>is displayed by by "module list" is real different.
>
>Bug or feature?
>
Was there ever a spec or requirement for such?  I don't think so, but it 
would be a nice feature, in my opinion, if the module list implied the 
order of load.  It could help in debuging problems where environment 
variables get stomped on, etc.

Dave

[Modules] Order of items in "module list"

[Harlan S. <Har...@pf...>]

Does the order in which modulefiles are displayed by "module list" have
anything to do with load order?

I ask because I have put "module load" commands in specific order in certain
"master" modulefiles, and I notice that the order in which these modulefiles
is displayed by by "module list" is real different.

Bug or feature?

H

Re: [Modules] Error running modules on AIX - Cannot initialize TCL

[Mark L. <la...@mi...>]

Yes, I've seen this before. I traced it back to our TCL installation not being
properly installed, but there was a work around setting an environment variable
to find the TCL initialization script.  Unfortunately, I don't remember what it
was, and I'm too busy to go hunting. sorry.. you'll want to point to init.tcl,
which is somewhere under /usr/local/lib/tcl8.* usually.

-Mark


Mark Lakata, Staff Engineer    1225 Charleston Road       voice 650-567-5170
MIPS Technologies              Mountain View CA 94043     fax   650-567-5002

On Thu, 17 Oct 2002, Thomas Leung wrote:

> Hi,
> 
> I keep seeing the "init.c(425):ERROR:159: Cannot initialize TCL" error when
> using modules on AIX.  The LD_LIBRARY_PATH variable is not set and ldd
> command is not available on AIX for me to check what is dependent upon the
> module command.  Has anyone come up upon this error before?
> 
> Thanks,
> 
> Thomas Leung
> 

[Modules] Error running modules on AIX - Cannot initialize TCL

[Thomas L. <tl...@br...>]

Hi,

I keep seeing the "init.c(425):ERROR:159: Cannot initialize TCL" error when
using modules on AIX.  The LD_LIBRARY_PATH variable is not set and ldd
command is not available on AIX for me to check what is dependent upon the
module command.  Has anyone come up upon this error before?

Thanks,

Thomas Leung

Re: [Modules] Fwd: question regarding env var manipulation

[Harlan S. <Har...@pf...>]

The speed thing is relative.

I also notice the "slowness" of modules.

One issue that makes this worse for me (and probably for Andy, as he and I
set this up where he is working) is that there are two ways to handle shell
RC stuff:

- do most things once at login time

- do nothing special at login; do everything at each shell startup

Over the years I have had enough trouble with the former (do it once per
session, at startup) that I now reset the shell "setup" (I didn't want to
say "environment") on every new shell process.

The biggest problem I see with "do it once" is that "often enough" some
chain of events will run a security-conscious program that scrubs the PATH
or other environment things and then calls sub-processes, and if/when these
sup-processes find their way back into one of my project scripts I need my
expected path and other environment variables.

I hope I described this clearly...

If there is a better way to go I'd love to know about it.

H

RE: [Modules] Fwd: question regarding env var manipulation

[Leo B. <lb...@br...>]

Andy Bruce (AB...@ap...) wrote:

> Sorry to interject--but beware of append_path, set_path, and
> prepend_path. I spent some time putting in support for embedded
> spaces (easy) and trying to "auto-magically" support differences
> between "c:\" and "/cygdrive/c" formats (problematic at best).
Andy Bruce (AB...@ap...) wrote:

> Sorry to interject--but beware of append_path, set_path, and
> prepend_path. I spent some time putting in support for embedded
> spaces (easy) and trying to "auto-magically" support differences
> between "c:\" and "/cygdrive/c" formats (problematic at best).

Hello, Andy.

Goodness, it's a mailing list with a voluntarily captive audience.
No apologies required -- discussion is always welcome.  :-)

What's problematic about the *-path statements?  The only issue
I've ever run into with their use is when multiple modulefiles
want to add the same information to a given env var.  I've used
some Tcl code to manage that, but I've never seen these routines
do anything they shouldn't.

> During this port I did some perf testings on append_path/set_path/
> prepend_path vs. pure-TCL, fully expecting it to be much faster
> than, say: setenv PATH "$env(PATH):some_new_path"
>
> After all--it's compiled C code.
>
> However, it was not faster. It was measurably slower than using
> the all-TCL code listed above. (Sorry, I don't have the numbers
> anymore, but I could redo the test if there's interest.)

Wow, was that causing you any problems?  We use a project modulefile
to in turn load a dozen other modulefiles, and I can load, unload
or switch these out in a couple of seconds.  Just curious what sort
of magnitude of delay you were running into; I've never even thought
about modules being slow thus far.

Regards,

- Leo Butler

RE: [Modules] Fwd: question regarding env var manipulation

[Andy B. <AB...@ap...>]

Sorry to interject--but beware of append_path, set_path, and prepend_path. I
spent some time putting in support for embedded spaces (easy) and trying to
"auto-magically" support differences between "c:\" and "/cygdrive/c" formats
(problematic at best).
 
Keep in mind that certain paths like CLASSPATH must always be in OS-specific
format--even when spawning the affected application under a *NIX-like shell.
 
During this port I did some perf testings on
append_path/set_path/prepend_path vs. pure-TCL, fully expecting it to be
much faster than, say:
    setenv PATH "$env(PATH):some_new_path"
 
After all--it's compiled C code.
 
However, it was not faster. It was measurably slower than using the all-TCL
code listed above. (Sorry, I don't have the numbers anymore, but I could
redo the test if there's interest.)
 
Instead of using the modules-specific xxx_path extensions, I found it to be
faster to use the above syntax and write a routine that can post-process a
path variable, removing duplicates.
 
I've attached some scripts that I use for this purpose--I hope they are
useful for you. Once again, I was surprised that they were actually faster
than using the built-ins.
 
Maybe I'm missing something obvious here, but these work well for me on all
the platforms we use.
 
proc safepath_create { var } {
  global env
  if {![info exists env($var)]} {
    setenv $var ""
  }
}
 
proc safepath_append { var value } {
  global env
  safepath_create $var
  setenv $var "$env($var):$value"
}
 
proc safepath_prepend { var value } {
  global env
  safepath_create $var
  setenv $var "$value:$env($var)"
}
 
proc reducepath { optimized args result } {
  # get these from the global namespace
  global argv
  global env
 
  # assume that the user passes the path to analyze to us
  foreach arg [split $args :] {
    # if empty, continue
    if { ![string compare $arg {}] } { continue }
 
    # normalize the string
    set pathName "$arg" ;
 
    # first, replace HOME refs with a tilde
    if { $optimized } {
      #  yuck, this may not work on all shells...
      regsub ^$env(HOME)/ $pathName ~/ pathName
    } else {
      # even though this makes the path passed in longer
      # it makes the directory reference resolvable by
      # all programs (can you say "ld loader?").
      regsub ^~/ $pathName $env(HOME)/ pathName
    }
 
    # TCL puts a curly-brace around things...
    regsub ^{ $pathName {} pathName
    regsub }$ $pathName {} pathName
 
    # now, replace spaces with an underscore
    regsub -all { } $pathName _ arName
 
    # in the array?
    if { ! [info exists pathsByName($arName)] } {
      set pathsByName($arName) $pathName
      lappend paths $pathName
    }
  }
 
  # and join 'em together
  if { [info exists paths] } {
    set newPath [join "$paths" :]
  } else {
    set newPath ""
  }
  upvar $result _result
  set _result $newPath
}
    

-----Original Message-----
From: Leo Butler [mailto:lb...@br...]
Sent: Friday, October 11, 2002 14:42
To: 'Nancy E. Davis'
Cc: mod...@li...
Subject: RE: [Modules] Fwd: question regarding env var manipulation



Nancy E. Davis (ne...@fa...) wrote: 

> Leo, 
> 
> Thanks much!  This works well as below: 
> 
> set flags_add { 
>     -L/usr/shlib -L/usr/ccs/lib -L/usr/lib/cmplrs/cc -L/usr/lib 
>     -L/usr/local/lib -L/ 
> var/shlib 
> } 
> 
> if {([module-info mode load] || [module-info mode switch2]) && [info
exists env(DEC_CC)]} { 
>     setenv _SAVE_DEC_CC $env(DEC_CC) 
>     set flags_use [concat $flags_add $env(DEC_CC)] 
>     setenv DEC_CC $flags_use 
> } else { 
>     set flags_end " | " 
>     set flags_use [concat $flags_add $flags_end] 
>     setenv DEC_CC $flags_use 
> } 
> 
> For now, this is enough.  Once I learn more tcl, I can think about 
> replacing the saved env var.  I would also like to figure out 
> how to do some sanity checking on the list and avoid replicate 
> entries.  Some users are coming in with no flags set, others have 
> a very specific list that include some or all of the flags I want 
> them to be certain to have. 
> 
> Thanks to all for your help. 

Hello, Nancy. 

If you can think of a way to make use of "append-path", it would 
be easiest to work with in modules.  So you'd end up with the usual 
colon-delimited list, but perhaps you could process that into a 
space-delimited list in your compile process. 

We have a setup in our modulefiles that allows us to set a particular 
env var if not already set, but when unloading one of the modulefiles 
that sets the env var we have some Tcl that prevents the var from being 
unsetenv *unless* the modulefile is the last of the bunch that needs it 
set.  It will then be allowed to unsetenv the var.  It's essentially 
a "last one out of the house shuts the door" function. 

This works very well, but currently requires that each modulefile 
know about the others (use of env vars indicating certain modulefiles 
have been loaded).  Depending upon how many modulefiles would need 
to set the same set of libraries in your environment, this might work 
for you or could get very messy very fast.  If most of the lib paths 
are mutually exclusive, it should be okay. 

Just some thoughts.  Good luck! 

- Leo Butler 

RE: [Modules] Fwd: question regarding env var manipulation

[Leo B. <lb...@br...>]

Nancy E. Davis (ne...@fa...) wrote:

> Leo, 
> 
> Thanks much!  This works well as below:
> 
> set flags_add {
>     -L/usr/shlib -L/usr/ccs/lib -L/usr/lib/cmplrs/cc -L/usr/lib
>     -L/usr/local/lib -L/
> var/shlib
> }
> 
> if {([module-info mode load] || [module-info mode switch2]) && [info
exists env(DEC_CC)]} {
>     setenv _SAVE_DEC_CC $env(DEC_CC)
>     set flags_use [concat $flags_add $env(DEC_CC)]
>     setenv DEC_CC $flags_use
> } else {
>     set flags_end " | "
>     set flags_use [concat $flags_add $flags_end]
>     setenv DEC_CC $flags_use
> }
> 
> For now, this is enough.  Once I learn more tcl, I can think about
> replacing the saved env var.  I would also like to figure out 
> how to do some sanity checking on the list and avoid replicate
> entries.  Some users are coming in with no flags set, others have
> a very specific list that include some or all of the flags I want
> them to be certain to have.
> 
> Thanks to all for your help.

Hello, Nancy.

If you can think of a way to make use of "append-path", it would
be easiest to work with in modules.  So you'd end up with the usual
colon-delimited list, but perhaps you could process that into a
space-delimited list in your compile process.

We have a setup in our modulefiles that allows us to set a particular
env var if not already set, but when unloading one of the modulefiles
that sets the env var we have some Tcl that prevents the var from being
unsetenv *unless* the modulefile is the last of the bunch that needs it
set.  It will then be allowed to unsetenv the var.  It's essentially
a "last one out of the house shuts the door" function.

This works very well, but currently requires that each modulefile
know about the others (use of env vars indicating certain modulefiles
have been loaded).  Depending upon how many modulefiles would need
to set the same set of libraries in your environment, this might work
for you or could get very messy very fast.  If most of the lib paths
are mutually exclusive, it should be okay.

Just some thoughts.  Good luck!

- Leo Butler

RE: [Modules] Fwd: question regarding env var manipulation

[Nancy E. D. <ne...@fa...>]

On Thu, 10 Oct 2002 15:26:23 -0700, "Leo Butler" <lb...@br...>
said:
> Nancy E. Davis (ne...@fa...) wrote:
> 
> > Hi Modules-interest,
> > 
> > I am working with modules version 3.1.6 on Tru64 Unix, Tcl 8.4a1.
> > I want to evaluate a users env var and use the module file to
> > manipulate it.  The env var in question is a space delimited list
> > of compiler options, i.e., 
> > 
> > me@host> echo $DEC_CC
> > -L/usr/local/lib -L/var/shlib |
> > 
> > When a user loads a particular module, I want to evaluate if they
> > have DEC_CC set, what it is set to, and make certain more paths
> > are included.  When said user unloads a module, I want to recall
> > the previous env var and give them back what they had.
> > 
> > Is this possible?  I'm having trouble getting the env var out of
> > the users environment in any form.  If this isn't possible, can I
> > source a script at the end of the modulefile to do this?
> 
> Hello, Nancy.
> 
> You can try something like this:
> 
> if {([module-info mode load] || [module-info mode switch2]) && [info
> exists
> env(DEC_CC)]} {
>   setenv _SAVE_DEC_CC $env(DEC_CC)
>   # Now do some regexp stuff in here to process DEC_CC
> } else {
>   # Remove specific items added during loading of this module
> }

Leo, 

Thanks much!  This works well as below:

set flags_add {
    -L/usr/shlib -L/usr/ccs/lib -L/usr/lib/cmplrs/cc -L/usr/lib
    -L/usr/local/lib -L/
var/shlib
}

if {([module-info mode load] || [module-info mode switch2]) && [info
exists env(DEC_
CC)]} {
    setenv _SAVE_DEC_CC $env(DEC_CC)
    set flags_use [concat $flags_add $env(DEC_CC)]
    setenv DEC_CC $flags_use
} else {
    set flags_end " | "
    set flags_use [concat $flags_add $flags_end]
    setenv DEC_CC $flags_use
}

For now, this is enough.  Once I learn more tcl, I can think about
replacing the saved env var.  I would also like to figure out how to do
some sanity checking on the list and avoid replicate entries.  Some users
are coming in with no flags set, others have a very specific list that
include some or all of the flags I want them to be certain to have.

Thanks to all for your help.

Best regards,

Nancy Davis

RE: [Modules] Fwd: question regarding env var manipulation

[Leo B. <lb...@br...>]

A footnote that I should mention to the previous email;
as soon as I hit send I realized the example assumed csh
or variant, so would break modules' shell independence.
I don't recommend using the "puts" statement under any
circumstance for that reason.

Regards,

- Leo

RE: [Modules] Fwd: question regarding env var manipulation

[Leo B. <lb...@br...>]

Nancy E. Davis (ne...@fa...) wrote:

> Hi Modules-interest,
> 
> I am working with modules version 3.1.6 on Tru64 Unix, Tcl 8.4a1.
> I want to evaluate a users env var and use the module file to
> manipulate it.  The env var in question is a space delimited list
> of compiler options, i.e., 
> 
> me@host> echo $DEC_CC
> -L/usr/local/lib -L/var/shlib |
> 
> When a user loads a particular module, I want to evaluate if they
> have DEC_CC set, what it is set to, and make certain more paths
> are included.  When said user unloads a module, I want to recall
> the previous env var and give them back what they had.
> 
> Is this possible?  I'm having trouble getting the env var out of
> the users environment in any form.  If this isn't possible, can I
> source a script at the end of the modulefile to do this?

Hello, Nancy.

You can try something like this:

if {([module-info mode load] || [module-info mode switch2]) && [info exists
env(DEC_CC)]} {
  setenv _SAVE_DEC_CC $env(DEC_CC)
  # Now do some regexp stuff in here to process DEC_CC
} else {
  # Remove specific items added during loading of this module
}

Remember to think about the unload case carefully; putting Tcl flow
control statements around modules commands using [module-info mode
"load"] and the like can hide those modules commands.  Use some
"puts stderr" statements in your code for debugging; it helps a lot.

The thing I think you'll have trouble with is the spaces.  The
append-path statement uses colons, so I think you're stuck using
setenv to add/subtract from DEC_CC.  But the "undo" of setenv
(which occurs when you "module unload) is to completely remove the
variable, independent of what it was set to in the first place.  For
example, put "setenv DEC_CC blah" inside the else statement above
and you'll find that DEC_CC isn't defined after an unload, even
though it wasn't equal to "blah" during the unload.

So I don't think you can have DEC_CC exist when loading your
modulefile, add to it via a setenv during load (which is the
only way to get a space as a delimiter), and get back the original
after doing an unload.

Hmmm... something I just hacked into a test seems to have worked,
although I'd love for someone to weigh in as to just how bad an
idea it might be to do this.

puts -nonewline "setenv DEC_CC \"-L/usr/lib -L/shlib\";"
flush stdout ;

You can output your own custom commands using this, even during
an unload.  Scary, but it may work for you.  ;-)  Note that this
string will be put up front of any output from modules (which will
be passed to "eval" in the shell).

Hope this helps,

- Leo

Re: [Modules] Fwd: question regarding env var manipulation

[Harlan S. <Har...@pf...>]

Did you try:

 set DEC_CC $env(DEC_CC)

in your modulefile?

H

[Modules] Fwd: question regarding env var manipulation

[Nancy E. D. <ne...@fa...>]

On Thu, 10 Oct 2002 21:12:01 UT, "Nancy E. Davis" <ne...@fa...>
said:
> Hi Modules-interest,
> 
> I am working with modules version 3.1.6 on Tru64 Unix, Tcl 8.4a1.
> I want to evaluate a users env var and use the module file to manipulate
> it.  The env var in question is a space delimited list of compiler
> options, 
> i.e., 
> 
> me@host> echo $DEC_CC
> -L/usr/local/lib -L/var/shlib |
> 
> When a user loads a particular module, I want to evaluate if they have
> DEC_CC
> set, what it is set to, and make certain more paths are included.  When
> said
> user unloads a module, I want to recall the previous env var and give
> them
> back what they had.
> 
> Is this possible?  I'm having trouble getting the env var out of the
> users 
> environment in any form.  If this isn't possible, can I source a script
> at
> the end of the modulefile to do this?
> 
> Thanks for any insight you can provide.  If further info is needed, it
> will be
> gladly supplied.
> 
> Nancy Davis

Re: [Modules] Strange LD_LIBRARY_PATH issue with 3.1.6 on RedHat 7.1

[Leo B. <lb...@br...>]

Leo Butler (lb...@br...) wrote:

> A funny thing happened very suddenly on our Linux servers
> that I'm at a loss to explain.  The basic problem is this:
>
> RedHat 7.1, modules 3.1.6
>
> Log into a Linux system, load up several modulefiles for
> some EDA software, then try to run another module command
> and we get the error:
>
> init.c(425):ERROR:159: Cannot initialize TCL
>
> Turns out the reason this happens is due to adding a new
> library to the LD_LIBRARY_PATH from one of the EDA tools,
> DesignSync from Synchronicity "lib.Linux".  Take that out
> of the LD_LIBRARY_PATH and modules starts working again.

The issue is resolved.  The Synchronicity tools don't need
to have the lib.Linux path set in the LD_LIBRARY_PATH, so
I can remove it and the correct libtcl8.3.so will be found
in /usr/lib instead of down inside the Synchronicity lib
directory.

I also found that putting /usr/lib up front in LD_LIBRARY_PATH
took care of the issue as well.  Interesting that 3.1.5
didn't care about what was in the LD_LIBRARY_PATH but 3.1.6
did; both versions were generated using dynamic libraries,
so it wasn't because of that.

Regards,

- Leo Butler

[Modules] Strange LD_LIBRARY_PATH issue with 3.1.6 on RedHat 7.1

[Leo B. <lb...@br...>]

Hello.

A funny thing happened very suddenly on our Linux servers
that I'm at a loss to explain.  The basic problem is this:

RedHat 7.1, modules 3.1.6

Log into a Linux system, load up several modulefiles for
some EDA software, then try to run another module command
and we get the error:

init.c(425):ERROR:159: Cannot initialize TCL

Turns out the reason this happens is due to adding a new
library to the LD_LIBRARY_PATH from one of the EDA tools,
DesignSync from Synchronicity "lib.Linux".  Take that out
of the LD_LIBRARY_PATH and modules starts working again.

And interestingly, version 3.1.5 does not exhibit this issue.

So what could have caused this?  I'd like to isolate what
the issue is so I know who to ask to fix it.  If the folks
at Synchronicity took over a Tcl function or something like
that, I'd like to be able to explain it to them so they can
fix it in their next release.  If it's a modules thing, it
would of course be nice to patch it.  :-)

By the way, this wasn't an issue up until today.  There was
a lot of work done on our network infrastructure and storage
pool, and today this issue was all of a sudden there.  I've
looked at the Linux servers and none of them received any
RPM updates, so the software versions haven't changed.  I'm
at a loss to explain how anything IT did could have caused
this.

Thanks,

- Leo