modules-interest — Discussion forum for modules usage.

Re: [Modules] module update cause ModuleCmd_Use.c(224):ERROR:64

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

I've added a new command to the tcl version that purges all modules. This
is useful for reseting the environment, ie.

.login:

 module purge
 module load myproject/all


btw, has anyone else looked at the pure TCL version yet? Unless you need
deep modulefile trees (more than $tool/$version), there is no reason not
to use the TCL version instead.  Installation on any machine (including
cygwin) is as easy as

1. first make sure tclsh in /usr/bin/ or /usr/local/bin or on the default
system path

2. 
  mv modulecmd.tcl init /the/module/dir
  cd /the/module/dir/init; make


-Mark

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

On 29 May 2003, Leo Butler wrote:

> On Thu, 2003-05-29 at 19:03, Harlan Stenn wrote:
> 
> > Would it be a good idea to either completely remove .modulesbeginenv
> > from the code or to make it "optional"?
> > 
> > Leo, how did you get rid of it?
> > 
> > I will need to solve this by Monday...
> 
> Hi, Harlan.
> 
> Heh-heh... I simply failed to ever tell anyone about using
> it.  The instructions I wrote up tells users to re-source
> their .cshrc which cleans out any env vars that might other-
> wise get appended to and then resets their environment using
> the *_VER variables (SYNOPSYS_VER, VIM_VER, etc.) that we
> set in each modulefile.  It's a bit of a workaround but it
> has been working wellfor us.  Note that it's not exactly the
> same as 'module update' but it implements the feature that
> we want.
> 
> We load default versions of all necessary tools on a per-
> project basis with a "modulefile of modulefiles" that sets
> default versions of tools using these *_VER vars *if* they
> weren't set already.  If set, the version pointed to by the
> variable is loaded.  So we get a clean version of the current
> environment, not the original environment.  Hope this made
> sense...
> 
> The .modulesbeginenv file is not deleted, but goes unused.
> I would indeed recommend that we eliminate it from modules
> and find some other mechanism to reset the environment.
> 
> Regards,
> 
> - Leo
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
> 

Re: [Modules] module update cause ModuleCmd_Use.c(224):ERROR:64

[Leo B. <le...@le...>]

On Thu, 2003-05-29 at 19:03, Harlan Stenn wrote:

> Would it be a good idea to either completely remove .modulesbeginenv
> from the code or to make it "optional"?
> 
> Leo, how did you get rid of it?
> 
> I will need to solve this by Monday...

Hi, Harlan.

Heh-heh... I simply failed to ever tell anyone about using
it.  The instructions I wrote up tells users to re-source
their .cshrc which cleans out any env vars that might other-
wise get appended to and then resets their environment using
the *_VER variables (SYNOPSYS_VER, VIM_VER, etc.) that we
set in each modulefile.  It's a bit of a workaround but it
has been working wellfor us.  Note that it's not exactly the
same as 'module update' but it implements the feature that
we want.

We load default versions of all necessary tools on a per-
project basis with a "modulefile of modulefiles" that sets
default versions of tools using these *_VER vars *if* they
weren't set already.  If set, the version pointed to by the
variable is loaded.  So we get a clean version of the current
environment, not the original environment.  Hope this made
sense...

The .modulesbeginenv file is not deleted, but goes unused.
I would indeed recommend that we eliminate it from modules
and find some other mechanism to reset the environment.

Regards,

- Leo

Re: [Modules] module update cause ModuleCmd_Use.c(224):ERROR:64

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

Would it be a good idea to either completely remove .modulesbeginenv from
the code or to make it "optional"?

Leo, how did you get rid of it?

I will need to solve this by Monday...

H

RE: [Modules] module update cause ModuleCmd_Use.c(224):ERROR:64

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

Haugli, Raymond (Ray...@ko...) wrote:

> Thanks for all the help regarding aliases.  I have one
> other problem as well:
> 
> When I run the command 'module update' it results in this
> error message:
>   ModuleCmd_Use.c(244):ERROR:64: Directory '/home/raymondh
>   /privatemodules' not found
>   common/1.0(35):ERROR:102: Tcl command execution failed: module use
>   --append $ownmoddir
> 
> I have this line in my modulefile common/1.0:
>   eval set [ array get env HOME ]
>   set ownmoddir $HOME/privatemodules
>   module use --append $ownmoddir
> 
> If I understand things correctly, when you run 'module update',
> the environment is cleared, and the file $HOME/.modulesbeginenv
> is sourced to set back the environment.  Then the modules are
> loaded.
> 
> For some reason, it looks like there is a linefeed (or space) at
> the end of the env-var $HOME, when it's fetched from $HOME/
> .modulesbeginenv.  There are of course, no extra linefeed (or
> spaces) at the end of the $HOME-var in $HOME/.modulesbeginenv.
> This is very strange, and it doesn't happend to other env-var
> fetched from $HOME/.modulesbeginenv.
> 
> I appreciate every tips on this issue.

Hello, Ray.

There are a number of reasons to avoid using the
.modulesbegin file for anything, the main one being
multiple system architectures coexisting with a
common HOME directory.  If you depend upon it and
you mix say, Solaris and Linux, you're going to have
a mess.

The way we use modules is to load everything up in
the .cshrc (and I have a bit of code at the top of
that file that does a 'unsetenv VAR' on all of the
modules environment variables) so that we can reload
the default environment simply by re-sourcing the
.cshrc.  This works pretty cleanly for all of the
various methods of invoking a new shell (rlogin to
the same/different architecture machine, su, ssh,
etc.) that we use.

Now, to answer your question more directly, since I
don't use this modules "feature" I'm not sure why
it's happening.  I would suggest trying $env(HOME)
instead of what you're using now to just see if it
works.  I've not used the array command with eval
as you had before.

Regards,

- Leo

[Modules] module update cause ModuleCmd_Use.c(224):ERROR:64

[Haugli, R. <Ray...@ko...>]

Hi.
=20
Thanks for all the help regarding aliases.  I have one other problem as
well:
=20
When I run the command 'module update' it results in this error message:
  ModuleCmd_Use.c(244):ERROR:64: Directory '/home/raymondh
  /privatemodules' not found
  common/1.0(35):ERROR:102: Tcl command execution failed: module use
  --append $ownmoddir
=20
I have this line in my modulefile common/1.0:
  eval set [ array get env HOME ]
  set ownmoddir $HOME/privatemodules
  module use --append $ownmoddir
=20
If I understand things correctly, when you run 'module update', the
environment is cleared, and the file $HOME/.modulesbeginenv is sourced
to set back the environment.  Then the modules are loaded.
=20
For some reason, it looks like there is a linefeed (or space) at the end
of the env-var $HOME, when it's fetched from $HOME/.modulesbeginenv.
There are of course, no extra linefeed (or spaces) at the end of the
$HOME-var in $HOME/.modulesbeginenv. This is very strange, and it
doesn't happend to other env-var fetched from $HOME/.modulesbeginenv.
=20
I appreciate every tips on this issue.
=20
I'm still ( ;) ) using Modules v3.1.6 on Sun Solaris 8.
=20
br /Ray
----------------------------------------
 Raymond Haugli - Working with CM & CC
     ray...@ko... <mailto:ray...@ko...>=20
     work: +47 3228 7495
     mob: +47 9082 5962
=20


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MAILsweeper for the presence of computer viruses.

Best regards,
Kongsberg Gruppen
**********************************************************************

Re: [Modules] Aliases disappear with bash

[Leo B. <le...@le...>]

Haugli, Raymond wrote:

> Hi.
> 
> I have a problem with using aliases in bash.  Whenever I start a new 
> xterm-window or start a new shell, I loose all my aliases.  I've tried 
> to set my aliases in a modulefile like this:
> 
> set-alias       h       history
> set-alias       gtar    'gtar'
> set-alias       ll      "ls -l"
> 
> None of them survive when I start a new shell.  Can someone help me with 
> this problem?
> 
> I am using modules version 3.1.6 with Sun Solaris 8.

Hello, Ray.

Basic aliases are probably more appropriate to load in your
.bashrc which ought to be sourced upon startup of a new shell.
Now when it comes to aliases for programs you've loaded a
modulefile for, the only solutions I know of are to either
avoid the use of aliases altogether or to be sure your env
gets reloaded at each shell invocation (meaning reload all
of the modulefiles).

I'm not a full-time bash user, but as I recall the bashrc
will be reloaded upon shell startup.  I just tried this on
my Linux system, but can't test it out under Solaris at the
moment.  I would hope you wouldn't have to pass an option
to xterm to force the shell to be a login shell to get this
to work.

The mechanism I described is what we do for Solaris/Linux
and it has worked well in this regard (but note it is under
csh/tcsh in all but one case).

Hope this helps,

- Leo

Re: [Modules] Aliases disappear with bash

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

Aliases are not inherited like environment variables. There is not much
you can do, except to avoid aliases in modules OR reload the modules in
the new shell ( you can put the "module load ..." commands in your .cshrc
instead of .login )

-Mark

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

On Wed, 14 May 2003, Haugli, Raymond wrote:

> Hi.
> 
> I have a problem with using aliases in bash.  Whenever I start a new xterm-window or start a new shell, I loose all my aliases.  I've tried to set my aliases in a modulefile like this:
> 
> set-alias	h	history
> set-alias	gtar	'gtar'
> set-alias	ll	"ls -l"
> 
> None of them survive when I start a new shell.  Can someone help me with this problem?
> 
> I am using modules version 3.1.6 with Sun Solaris 8.
> 
> Br /Ray
> ----------------------------------------
>  Raymond Haugli - Working with CM & CC
>      ray...@ko...
>      work: +47 3228 7495
>      mob: +47 9082 5962
> 
> 

[Modules] Aliases disappear with bash

[Haugli, R. <Ray...@ko...>]

Hi.

I have a problem with using aliases in bash.  Whenever I start a new =
xterm-window or start a new shell, I loose all my aliases.  I've tried =
to set my aliases in a modulefile like this:

set-alias	h	history
set-alias	gtar	'gtar'
set-alias	ll	"ls -l"

None of them survive when I start a new shell.  Can someone help me with =
this problem?

I am using modules version 3.1.6 with Sun Solaris 8.

Br /Ray
----------------------------------------
 Raymond Haugli - Working with CM & CC
     ray...@ko...
     work: +47 3228 7495
     mob: +47 9082 5962

Re: [Modules] Windows port of modules? Anyone try it?

[Larry W. V. <lv...@ca...>]

From: Phi...@mo...

> One problem is that we're not supporting Cygwin, so I'm handicapped by
> the lack of a UNIX-like development environment.

Are you opposed to supporting any Unix-like dev environment - or just
cygwin?

There are others - MKS Toolkit, one by David Korn called UWIN, etc.
-- 
Tcl - The glue of a new generation.  <URL: http://wiki.tcl.tk/ >
Larry W. Virden <mailto:lv...@ca...> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
-><-

Re: [Modules] Windows port of modules? Anyone try it?

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

> Actually, we don't use the more esoteric features, although we do have
> a module directory heirarchy that is about 3 or 4 layers deep.   
> 
> What I mean is, most module load commands like like:
> 
>      module load foo/bar/1.0
> 
> where "foo/bar/1.0" is found relative to one of the directories in the
> $MODULEPATH.


the tcl version only supports 2 and only 2 levels of directory hierarchy. it
might not be very hard to fix though, as long as the model is clear. our
methodology is

 module load foo

means

 module load foo/<default_version>

I'm not sure what it means if you have a hierarchy. I haven't looked at the
latest c-source code to see what it does.


-Mark

Re: [Modules] Windows port of modules? Anyone try it?

[<Phi...@mo...>]

>>>>> "Mark" == Mark Lakata <la...@mi...> writes:

Mark> I would port the 'modulecmd.tcl' implementation that I wrote
Mark> instead of the c-based source code.  Chances are, it will work
Mark> out of the box on Cygwin, and with a minimum of tweaking for
Mark> Windows.  Previously I tried porting the c source to cygwin, and
Mark> didn't get very far. The pure tcl code is much easier to deal
Mark> with.

Since Tcl is available for Windows, that might be the solution I'm
looking for.

Mark> The tcl source code is roughly 3% the size of the c source code,
Mark> and it runs much faster, so there really is no reason to use the
Mark> c source code, unless you need some of the more esoteric
Mark> features (deep module directories).

Actually, we don't use the more esoteric features, although we do have
a module directory heirarchy that is about 3 or 4 layers deep.   

What I mean is, most module load commands like like:

     module load foo/bar/1.0

where "foo/bar/1.0" is found relative to one of the directories in the
$MODULEPATH.

Mark> Look in the sourceforge CVS tree under tcl/

I'll check it out, thanks.

Re: [Modules] Windows port of modules? Anyone try it?

[<Phi...@mo...>]

>>>>> "Ed" == earthur  <ea...@at...> writes:

Ed> Maybe a port to Cygwin is possible (and easy?)
Ed> but what are you attempting to accomplish on
Ed> Windows?  What shell would you be using?

Well, we might not be using a shell at all.  We were considering
extending the supported "shells" to include things like support for
MS-DOS (spit out set commands).

We're interested in the generic mapping from a Tcl module file to the
shell-specific commands, interpreted by whowver calls modulecmd.
Currently, that is almost always a shell function called "module", but
I see no reason why we can't use the mechanism to configure a number
of different software systems.

One problem is that we're not supporting Cygwin, so I'm handicapped by
the lack of a UNIX-like development environment.

>> Here at Morgan Stanley, we are finally attempting to port (some of)
>> our UNIX systems management infrastructure to Windows, in order to
>> better manage the Windows plant.
>> 
>> We make use of modules pretty heavily (but if you've read the
>> README.perl file in the modules distro, you know this ;-), and would
>> like to leverage the same mechanism on Windows.
>> 
>> But, it appears noone has attempted a port to Windows.  Has anyone
>> done any work on this at all?  I'd be interested even in failed
>> attempts, so I can avoid repeating someone else's mistakes.
>> 
>> Is there any reason to beleive that it could NOT be ported?  Tcl is
>> already ported to Windows, so the biggest dependency is met.  I
>> presume we would have to disable X11 support, but that's not a huge
>> loss on Windows.
>> 
>> Is anyone else interested in using a Windows port, if we can get it
>> done?  

Re: [Modules] Windows port of modules? Anyone try it?

[<ea...@at...>]

Hi Phil,

Maybe a port to Cygwin is possible (and easy?)
but what are you attempting to accomplish on
Windows?  What shell would you be using?

/Ed

> 
> Here at Morgan Stanley, we are finally attempting to port (some of)
> our UNIX systems management infrastructure to Windows, in order to
> better manage the Windows plant.
> 
> We make use of modules pretty heavily (but if you've read the
> README.perl file in the modules distro, you know this ;-), and would
> like to leverage the same mechanism on Windows.
> 
> But, it appears noone has attempted a port to Windows.  Has anyone
> done any work on this at all?  I'd be interested even in failed
> attempts, so I can avoid repeating someone else's mistakes.
> 
> Is there any reason to beleive that it could NOT be ported?  Tcl is
> already ported to Windows, so the biggest dependency is met.  I
> presume we would have to disable X11 support, but that's not a huge
> loss on Windows.
> 
> Is anyone else interested in using a Windows port, if we can get it
> done?  

Re: [Modules] Windows port of modules? Anyone try it?

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

I would port the 'modulecmd.tcl' implementation that I wrote instead of the
c-based source code.  Chances are, it will work out of the box on Cygwin, and
with a minimum of tweaking for Windows.  Previously I tried porting the
c source to cygwin, and didn't get very far. The pure tcl code is much easier
to deal with.

The tcl source code is roughly 3% the size of the c source code, and it runs
much faster, so there really is no reason to use the c source code, unless you
need some of the more esoteric features (deep module directories).

Look in the sourceforge CVS tree under tcl/

-Mark


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

On Wed, 22 Jan 2003 Phi...@mo... wrote:

> 
> Here at Morgan Stanley, we are finally attempting to port (some of)
> our UNIX systems management infrastructure to Windows, in order to
> better manage the Windows plant.
> 
> We make use of modules pretty heavily (but if you've read the
> README.perl file in the modules distro, you know this ;-), and would
> like to leverage the same mechanism on Windows.
> 
> But, it appears noone has attempted a port to Windows.  Has anyone
> done any work on this at all?  I'd be interested even in failed
> attempts, so I can avoid repeating someone else's mistakes.
> 
> Is there any reason to beleive that it could NOT be ported?  Tcl is
> already ported to Windows, so the biggest dependency is met.  I
> presume we would have to disable X11 support, but that's not a huge
> loss on Windows.
> 
> Is anyone else interested in using a Windows port, if we can get it
> done?  
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Scholarships for Techies!
> Can't afford IT training? All 2003 ictp students receive scholarships.
> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> www.ictp.com/training/sourceforge.asp
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
> 

[Modules] Windows port of modules? Anyone try it?

[<Phi...@mo...>]

Here at Morgan Stanley, we are finally attempting to port (some of)
our UNIX systems management infrastructure to Windows, in order to
better manage the Windows plant.

We make use of modules pretty heavily (but if you've read the
README.perl file in the modules distro, you know this ;-), and would
like to leverage the same mechanism on Windows.

But, it appears noone has attempted a port to Windows.  Has anyone
done any work on this at all?  I'd be interested even in failed
attempts, so I can avoid repeating someone else's mistakes.

Is there any reason to beleive that it could NOT be ported?  Tcl is
already ported to Windows, so the biggest dependency is met.  I
presume we would have to disable X11 support, but that's not a huge
loss on Windows.

Is anyone else interested in using a Windows port, if we can get it
done?  

Re: [Modules] pure TCL implementation of module...

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

> >(1) faster
> >
> Do you have some hard data to support this claim?  The argument 
> typically goes the other way - compiled programs are faster than 
> interpreters because they are inherently slower.  However, if the 
> overall time is small, it may not matter.

We have a meta module that loads about 20-30 modules. It takes about 10 seconds
for the c-compiled version and 2 seconds for my tcl version. That is where I
based my factor of 5 speed up.
 
> >(2) no compiling needed
> >
> But the source code does need to be interpreted each and every time it 
> is executed.

yes, but see point (1). Also, all of the module files themselves are written in
tcl, so there is still a whole lot of tcl interpretation going on.


If you actually looked at the c-compiled version, you would see that isn't the
most efficient implementation. It does a lot of string manipulation; the same
type of manipulation that tcl does, and does well.

I'm not sure what changed between modules-2.2 and modules-3.0, but 2.2 used to
be much faster. 

One guess is that jumping into and out of TCL and coverting the TCL data
structures into c data structures is the overhead that causes the c-based
program to run slower, compared to the pure TCL version.


> >(3) easier to maintain, no porting needed to other machines >(4) smaller
> code (1 file!) >
> 
> These are very good points in favor of your implementation.
> 
> I hope you can clear up the copyright issue brought up by Leo Butler.

yes, the copyright message was inappropriate and was removed, since the script
is clearly under the GPL. The script is now just another file of the official
modules package.

-Mark

Re: [Modules] pure TCL implementation of module...

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

Mark Lakata wrote:

>I don't know why this wasn't tried earlier! I rewrote 'modules' as a pure TCL
>script. Advantages:
>
>(1) faster
>
Do you have some hard data to support this claim?  The argument 
typically goes the other way - compiled programs are faster than 
interpreters because they are inherently slower.  However, if the 
overall time is small, it may not matter.

>(2) no compiling needed
>
But the source code does need to be interpreted each and every time it 
is executed.

>(3) easier to maintain, no porting needed to other machines
>(4) smaller code (1 file!)
>

These are very good points in favor of your implementation.

I hope you can clear up the copyright issue brought up by Leo Butler.

Thanks for your interesting contribution.

Dave

>
>
>Can anyone explain to me if there is any reason at all to continue with the c
>based module command? This script only took me 6 hours to write, and as far as
>I can tell, it is much faster than the c based version (3).
>
>I only implemented the stuff that I care about, so none of the 'initload' stuff
>is in there. Basically just 'load, unload, switch, list, display and use'.
>Also, the module repository is not hierarchical, but I don't see a need for
>that. Also, I haven't tested it much for csh, but I'm sure it only requires a
>little hacking. And you should not be using csh anyways. :)
>
>-Mark
>
>  
>

Re: [Modules] pure TCL implementation of module...

[Leo B. <le...@le...>]

Mark Lakata wrote:

> I have checked in my pure TCL version of the modulecmd.tcl
 > script into the sourceforge repository.
> 
> We will switch to it here because it is a lot easier to
 > maintain (no porting required), smaller (the new script
 > is shorter than the old README) and roughly 5x faster than
 > the c-based 3.1.6 version. It doesn't have all the feature,
 > but it has everything that I want.
> 
> module help
>                 ModulesTcl 0.95 (Copyright MIPS Technologies 2002):
 > [snip]

Hello, Mark.

While you've made the code available to everyone, it
has a MIPS copyright.  What license, if any, is in effect
for its use?  I think you should be very explicit about
that, and be clear that you have MIPS' blessing to release
it.  Does it even need to be copyrighted by MIPS?

Don't get me wrong, I think it's pretty cool you did this
(in such a short amount of time, too) and I assume it's
okay with your employer.  It simply seems appropriate to
know this before using it.

Thanks,

- Leo

Re: [Modules] pure TCL implementation of module...

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

I have checked in my pure TCL version of the modulecmd.tcl script into the
sourceforge repository.

We will switch to it here because it is a lot easier to maintain (no porting
required), smaller (the new script is shorter than the old README) and roughly
5x faster than the c-based 3.1.6 version. It doesn't have all the feature, but
it has everything that I want.


module help
                ModulesTcl 0.95 (Copyright MIPS Technologies 2002):
                Available Commands and Usage:
                 add|load              modulefile [modulefile ...]
                 rm|unload             modulefile [modulefile ...]
                 reload
                 switch|swap           modulefile1 modulefile2
                 display|show          modulefile [modulefile ...]
                 avail                 [modulefile [modulefile ...]]
                 use                   dir [dir ...]
                 unuse                 dir [dir ...]
                 purge
                 list
                 whatis                [modulefile [modulefile ...]]
                 apropos|keyword       string
            
s


cheers,
Mark




Compare, and decide which version is easier to maintain ...

tcl version

-rwxr-xr-x   1 lakata   mips       22019 Nov 13 12:13 modulecmd.tcl*


c version

-rw-r--r--   1 lakata   mips       55141 Nov 29 11:04 ModuleCmd_Avail.c
-rw-r--r--   1 lakata   localbin    5507 Jun 17 10:26 ModuleCmd_Bootstrap.c
-rw-r--r--   1 lakata   mips        4901 Jun 27  2000 ModuleCmd_Clear.c
-rw-r--r--   1 lakata   mips        6214 Aug 14 10:10 ModuleCmd_Display.c
-rw-r--r--   1 lakata   localbin    7418 Jun 17 10:26 ModuleCmd_Help.c
-rw-r--r--   1 lakata   mips       15023 Aug 14 10:10 ModuleCmd_Init.c
-rw-r--r--   1 lakata   mips        5337 Nov 29 11:04 ModuleCmd_List.c
-rw-r--r--   1 lakata   mips        8834 Aug 14 10:10 ModuleCmd_Load.c
-rw-r--r--   1 lakata   mips        5177 Apr 30  2002 ModuleCmd_Purge.c
-rw-r--r--   1 lakata   mips        9420 Aug 14 10:10 ModuleCmd_Switch.c
-rw-r--r--   1 lakata   localbin    8902 Jun 17 10:26 ModuleCmd_Update.c
-rw-r--r--   1 lakata   localbin   10305 Jun 17 10:26 ModuleCmd_Use.c
-rw-r--r--   1 lakata   localbin   20378 Jun 17 10:26 ModuleCmd_Whatis.c
-rw-r--r--   1 lakata   mips        5750 Jun  9  2001 cmdAlias.c
-rw-r--r--   1 lakata   mips       16265 Aug 14 10:10 cmdConflict.c
-rw-r--r--   1 lakata   mips       12462 Aug 14 14:05 cmdInfo.c
-rw-r--r--   1 lakata   mips        6041 Aug 14 10:10 cmdIsLoaded.c
-rw-r--r--   1 lakata   mips        7054 Apr 30  2002 cmdLog.c
-rw-r--r--   1 lakata   mips        5864 Jun  9  2001 cmdMisc.c
-rw-r--r--   1 lakata   mips       25513 Apr 30  2002 cmdModule.c
-rw-r--r--   1 lakata   mips       23532 Aug 14 10:10 cmdPath.c
-rw-r--r--   1 lakata   mips       12865 Apr 25  2002 cmdSetenv.c
-rw-r--r--   1 lakata   mips       20098 Apr 30  2002 cmdTrace.c
-rw-r--r--   1 lakata   mips        6458 Jun  9  2001 cmdUlvl.c
-rw-r--r--   1 lakata   mips        7937 Jun 27  2000 cmdUname.c
-rw-r--r--   1 lakata   mips        4889 Jun  9  2001 cmdVerbose.c
-rw-r--r--   1 lakata   mips       42266 Nov 29 11:04 cmdVersion.c
-rw-r--r--   1 lakata   mips        6995 Jun  9  2001 cmdWhatis.c
-rw-r--r--   1 lakata   mips       29222 Apr 30  2002 cmdXResource.c
-rw-r--r--   1 lakata   mips       45242 Aug 14 10:10 error.c
-rw-r--r--   1 lakata   mips       38835 Jun  9  2001 getopt.c
-rw-r--r--   1 lakata   localbin   26202 Jun 17 10:26 init.c
-rw-r--r--   1 lakata   mips       36801 Nov 29 11:04 locate_module.c
-rw-r--r--   1 lakata   mips       22466 Nov 29 11:04 main.c
-rw-r--r--   1 lakata   mips       89980 Nov 29 11:04 utility.c
-rw-r--r--   1 lakata   mips         140 May 22  2002 version.c


-Mark



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

[Modules] Returned mail: recipient unknown

[The P. O. <pos...@wc...>]

A copy of your message is being returned to you because one or more of the
envelope addresses refers to an unknown local mailbox.

This is an automatic message.

error: pop: bi...@ma...

------- Original Message follows -------
external
rcvdfrom Eng.Auburn.EDU (dns.eng.auburn.edu [131.204.10.13])
with ESMTP
from <mod...@li...>
to <bi...@ma...>
Received: (from hendesf@localhost)
	by Eng.Auburn.EDU (8.11.6/8.11.6) id gAPDoPw23631;
	Mon, 25 Nov 2002 07:50:25 -0600 (CST)
Date: Mon, 25 Nov 2002 07:50:25 -0600 (CST)
From: mod...@li...
Message-Id: <200...@En...>
X-Authentication-Warning: dns.eng.auburn.edu: hendesf set sender to mod...@li... using -f
To: bi...@ma...
References: <200...@jo...>
In-Reply-To: <200...@jo...>
X-Loop: mod...@en...
Subject: modules-interest mail list moved

The modules-interest mail list has been moved to:

      mod...@li...

All members of the original list have been added to the new
list.  If you have questions or concerns please contact the
new list owner: Leo Butler <lb...@br...>.

Thanks.

Re: [Modules] multiple modules prepending to same env variable

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

"Jerry.Hershkowitz" wrote:

> Modules-interest list,

> load-ing a module, then subsequently unload-ing the same module,
> does not necessarily return your environment back to where it was
> prior to the load.  This is especially the case if several
> differnt modules use prepend-path or append-path to modify the
> same variable, and some of those modules add the same elements to
> the variable.  Does anyone know a reasonable way to write modules,
> such that after performing a unload of a module, your environment
> will be back to where it was prior to originally loading that
> module?
> 
> [snip]
> 
> What do other people do?

Hello, Jerry.

I use the following Tcl setup to allow multiple modulefiles
to share housekeeping of an environment variable.  The
tools all need to set the same string in the env var
"SNPSLMD_LICENSE_FILE" and we need to avoid the exact
situation you mention.

Each modulefile that needs to set this also sets another
env var that's a "version" variable, as so (using short
names instead of real [==long] names):

modulefile    env var    setting (example, value not important)
   A           A_VER       3.2
   B           B_VER       3.1
   C           C_VER       2.7

Modulefile A has the following Tcl code:

if {[module-info mode load] || !([info exists env(B_VER)] || [info exists env(C_VER)])} {
  setenv  SNPSLMD_LICENSE_FILE  1700@license1:1700@license2
}

Each modulefile has to have code that looks for the "*_VER"
env var existence of the other related modulefiles.  You
could probably use the newer "module is-loaded" command to
do this more robustly; our implementation is a couple of
years old and those commands weren't available at the time.
Also, we already had the "*_VER" variables in the modulefiles
so it was a natural fit.

This implements a "last one out the door shuts it" type of
housekeeping; unloading modulefile A only removes the string
from the env var if modulefiles B and C aren't loaded (as
they manage their own B_VER and C_VER env vars).

It's messy from a management perspective if you need to add
a new related modulefile in the future; every other modulefile
needs to be modified to know of the existence of the new one.
I'm sure someone could come up with a way to use a central
script to implement this, and that would be preferable.

Hope this helps,

- Leo

----------------------------------------------------------------------
Leo Butler                                         Staff ASIC Engineer
eBrocade Communications                           Phone: (408) 487-8096
1745 Technology Drive                            Fax:   (408) 392-6675
San Jose, CA 95110                          mailto:lb...@br...

Re: [Modules] multiple modules prepending to same env variable

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

We talked about having a "counter" for each setting, that knows that two
modules have loaded the same thing, so that unloading only happens if both
modules are unloaded.

however, that requires a pretty big change to the module command.

As a work around, you could make a unique symlinks to 'mydir', and then have
the modules use the symlink names instead of the real name. Then the
directories will appear to be unique. I'm not sure if this is a good idea...

The other idea is to never have modules use the same directory. Or if they do,
create a 'conflict' statement to prohibit both from being loaded at the same
time.

-Mark

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

On Tue, 29 Oct 2002, Jerry.Hershkowitz wrote:

> Modules-interest list,
> 
> load-ing a module, then subsequently unload-ing the same module, does not
> necessarily return your environment back to where it was prior to the
> load.  This is especially the case if several differnt modules use prepend-path 
> or append-path to modify the same variable, and some of those modules add the
> same elements to the variable.  Does anyone
> know a reasonable way to write modules, such that after performing
> a unload of a module, your environment will be back to where it was prior
> to originally loading that module?
> 
> For example:
> 
> --------------
> Module A:
> 
> prepend-path PATH mydir
> setenv OTHER_VAR1 valueA
> ==============
> 
> --------------
> Module B:
> 
> prepend-path PATH mydir
> setenv OTHER_VAR2 valueB
> ==============
> 
> We can see that both modules do different things (with OTHER_VAR1 and 
> OTHER_VAR2), but both happen to add the same directory to the PATH variable.
> 
> If we start with an undefined PATH environment variable (generally not the 
> case, but it makes this example easier to illustrate, and the effect would
> be the same if PATH did have a previous value), and we perform:
> 
> % module load A
> 
> PATH would now have the value "mydir", and "module list" would show that
> module A is loaded.  (Also, OTHER_VAR1 would have the value valueA.)   Let's 
> call this situation-1.
> 
> Next, if we perform:
> 
> % module load B
> 
> since prepend-path is smart enough not to duplicate an element in environment
> variable, and since "mydir" is already an element in the PATH variable, mydir
> is NOT added again to PATH.  PATH would now have just the value "mydir", and
> "module list" would show that both module A and module B are loaded.  
> (Also, OTHER_VAR1 would have the value valueA, and OTHER_VAR2 would have
> the value valueB.)  Let's call this situation-2
> 
> Now, if we were to unload B, I'd expect that just A would be loaded, and
> I'd expect my environment to be the same as situation-1.  But, if we
> try that, and perform:
> 
> % module unload B
> 
> the "prepend-path PATH mydir" in module B acts as a "remove-path PATH mydir",
> and therefore "mydir" is removed from PATH, and PATH now has nothing left
> in it (i.e. undefined).  "module list" would show that module A is loaded.
> (Also OTHER_VAR2 would correctly be unset, leaving OTHER_VAR1 correctly set
> to valueA.)  Let's call this situation-3.
> 
> Thus, the problem.  "module list" shows that module A is loaded.  OTHER_VAR1
> has the correct setting that module A performed.  But, despite module A
> being loaded, PATH does not have the value that module A applied to it.
> I would expect that our environment would appear identical to situation-1,
> but instead it is the different situation-3.
> 
> Is there anything I should be doing in my modules such that after unloading
> module B, my environment would be back to where it was after having just
> A loaded?  One thing I could think of is to include a "module update" command 
> in all of my modules.  But, if this needs to be added to all modules, maybe
> a module update should become a built-in part of "module unload".
> (Also, I've seen a strange problem related to "module update" that cause
> a TCL error when we use it sometimes, that I need to investigate further;  
> perhaps the subject of a future posting.)
> 
> What do other people do?
> 
> Thanks,
> 
> Jerry Hershkowitz
> Analog Devices
> Wilmington, MA
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
> 

[Modules] multiple modules prepending to same env variable

[Jerry.Hershkowitz <jer...@an...>]

Modules-interest list,

load-ing a module, then subsequently unload-ing the same module, does not
necessarily return your environment back to where it was prior to the
load.  This is especially the case if several differnt modules use prepend-path 
or append-path to modify the same variable, and some of those modules add the
same elements to the variable.  Does anyone
know a reasonable way to write modules, such that after performing
a unload of a module, your environment will be back to where it was prior
to originally loading that module?

For example:

--------------
Module A:

prepend-path PATH mydir
setenv OTHER_VAR1 valueA
==============

--------------
Module B:

prepend-path PATH mydir
setenv OTHER_VAR2 valueB
==============

We can see that both modules do different things (with OTHER_VAR1 and 
OTHER_VAR2), but both happen to add the same directory to the PATH variable.

If we start with an undefined PATH environment variable (generally not the 
case, but it makes this example easier to illustrate, and the effect would
be the same if PATH did have a previous value), and we perform:

% module load A

PATH would now have the value "mydir", and "module list" would show that
module A is loaded.  (Also, OTHER_VAR1 would have the value valueA.)   Let's 
call this situation-1.

Next, if we perform:

% module load B

since prepend-path is smart enough not to duplicate an element in environment
variable, and since "mydir" is already an element in the PATH variable, mydir
is NOT added again to PATH.  PATH would now have just the value "mydir", and
"module list" would show that both module A and module B are loaded.  
(Also, OTHER_VAR1 would have the value valueA, and OTHER_VAR2 would have
the value valueB.)  Let's call this situation-2

Now, if we were to unload B, I'd expect that just A would be loaded, and
I'd expect my environment to be the same as situation-1.  But, if we
try that, and perform:

% module unload B

the "prepend-path PATH mydir" in module B acts as a "remove-path PATH mydir",
and therefore "mydir" is removed from PATH, and PATH now has nothing left
in it (i.e. undefined).  "module list" would show that module A is loaded.
(Also OTHER_VAR2 would correctly be unset, leaving OTHER_VAR1 correctly set
to valueA.)  Let's call this situation-3.

Thus, the problem.  "module list" shows that module A is loaded.  OTHER_VAR1
has the correct setting that module A performed.  But, despite module A
being loaded, PATH does not have the value that module A applied to it.
I would expect that our environment would appear identical to situation-1,
but instead it is the different situation-3.

Is there anything I should be doing in my modules such that after unloading
module B, my environment would be back to where it was after having just
A loaded?  One thing I could think of is to include a "module update" command 
in all of my modules.  But, if this needs to be added to all modules, maybe
a module update should become a built-in part of "module unload".
(Also, I've seen a strange problem related to "module update" that cause
a TCL error when we use it sometimes, that I need to investigate further;  
perhaps the subject of a future posting.)

What do other people do?

Thanks,

Jerry Hershkowitz
Analog Devices
Wilmington, MA

[Modules] pure TCL implementation of module...

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

I don't know why this wasn't tried earlier! I rewrote 'modules' as a pure TCL
script. Advantages:

(1) faster
(2) no compiling needed
(3) easier to maintain, no porting needed to other machines
(4) smaller code (1 file!)


Can anyone explain to me if there is any reason at all to continue with the c
based module command? This script only took me 6 hours to write, and as far as
I can tell, it is much faster than the c based version (3).

I only implemented the stuff that I care about, so none of the 'initload' stuff
is in there. Basically just 'load, unload, switch, list, display and use'.
Also, the module repository is not hierarchical, but I don't see a need for
that. Also, I haven't tested it much for csh, but I'm sure it only requires a
little hacking. And you should not be using csh anyways. :)

-Mark



#!/usr/local/bin/tclsh
########################################################################
#
# This is a pure TCL implementation of the module command


########################################################################
# commands run from inside a module file
#

set ignoreDir(CVS) 1

proc module-info {what {more {}}} {
    global g_mode g_currentModule

    switch $what {
	"name" {
	    return $g_currentModule
	}
	"mode" {
	    if {$more != ""} {
		if {$g_mode == $more} {
		    return 1
		} else {
		    return 0
		}
	    } else {
		return $g_mode
	    }
	}
	default {
	    error "module-info $what not supported"
	}
    }
}

proc module-whatis {message} {
    if {$g_mode == "display"} {
	puts stderr "module-whatis\t$message"
    }
}

proc module {command args} {
    global g_mode

    switch $command {
	load {
	    if {$g_mode == "load"} {
		cmdModuleLoad $args
	    } elseif {$g_mode == "unload"} {
		cmdModuleUnload $args
	    } elseif {$g_mode == "display"} {
		puts stderr "module load $args"
	    }
	}
	default {
	    error "module $command not understood"
	}
    }
}

proc setenv {var val} {
    global g_newEnvVars g_delEnvVars env g_mode

    if {$g_mode == "load"} {
	set env($var) $val
	set g_newEnvVars($var) $val
    } elseif {$g_mode == "unload"} {
	if [info exists env($var)] {
	    unset env($var)
	}
	set g_delEnvVars($var) 1
    } elseif {$g_mode == "display"} {
	puts stderr "setenv\t$var\t$val"
    }
}

proc unsetenv {var} {
    global g_delEnvVars env g_mode
    
    if {$g_mode == "load"} {
	if [info exists env($var)] {
	    unset env($var)
	}
	set g_delEnvVars($var) 1
    } elseif {$g_mode == "display"} {
	puts stderr "unsetenv\t$var"
    }
}

proc unload-path {var dir} {
    global g_newEnvVars g_delEnvVars env

    if [info exists env($var)] {
	set dirs [split $env($var) ":"]
	set newpath ""
	foreach elem $dirs {
	    if {$elem != $dir} {
		lappend newpath $elem
	    }
	}
	if {$newpath == ""} {
	    unset env($var)
	    set g_delEnvVars($var) 1
	} else {
	    set env($var) [join $newpath ":"]
	    set g_newEnvVars($var) $env($var)
	}
    }
}

proc prepend-path {var dir} {
    global g_newEnvVars env g_mode

    if {$g_mode == "load"} {
	if [info exists env($var)] {
	    set env($var) "$dir:$env($var)"
	} else {
	    set env($var) "$dir"
	}
	set g_newEnvVars($var) $env($var)
    } elseif {$g_mode == "unload"} {
	unload-path $var $dir
    } elseif {$g_mode == "display"} {
	puts stderr "prepend-path\t$var\t$dir"
    }
}

proc append-path {var dir} {
    global g_newEnvVars env g_mode

    if {$g_mode == "load"} {
	if [info exists env($var)] {
	    set env($var) "$env($var):$dir"
	} else {
	    set env($var) "$dir"
	}
	set g_newEnvVars($var) $env($var)
    } elseif {$g_mode == "unload"} {
	unload-path $var $dir
    } elseif {$g_mode == "display"} {
	puts stderr "append-path\t$var\t$dir"
    }
}

proc set-alias {alias what} {
    global g_newAliases g_delAliases g_mode

    if {$g_mode == "load"} {
	set g_newAliases($alias) $what
    } elseif {$g_mode == "unload"} {
	set g_delAliases($alias) $what
    } elseif {$g_mode == "display"} {
	puts stderr "alias\t$alias\t$what"
    }
}


proc conflict {args} {
    global g_loadedModules g_loadedModulesGeneric g_mode g_currentModule

    if {$g_mode == "load"} {
	foreach conflict $args {
	    set mod [file dirname $conflict]
#puts stderr "mod=$mod"
	    if {$mod == "."} {
		if { [info exists g_loadedModulesGeneric($conflict) ] } {
		    set x $conflict/$g_loadedModulesGeneric($conflict)
		    if { $x != $g_currentModule } {
			error "Conflict with loaded module $x \nHINT: Do 'module unload $x' and then try again."
		    }
		}
	    } else {
		if { [info exists g_loadedModules($conflict)] &&
		     $conflict != $g_currentModule } {
		    error "Conflict ($g_currentModule) with loaded module: $conflict"
		}
	    }
	}
    } elseif {$g_mode == "display"} {
	puts stderr "conflict\t$args"
    }
}

proc x-resource {resource {value {_FILE_}}} {
    global g_newXResources g_delXResources g_mode
    
    if {$g_mode == "load"} {
	set g_newXResources($resource) $value
    } elseif {$g_mode =="unload"} {
	set g_delXResources($resource) 1
    } elseif {$g_mode == "display"} {
	puts stderr "x-resource\t$resource\$val"
    }
}

proc uname {what} {
    global unameCache
    if { ! [info exists unameCache($what)] } {
	switch $what {
	    sysname {
		catch { exec uname -s } result
	    }
	    machine {
		catch { exec uname -p } result
	    }
	    node {
		catch { exec uname -n } result
	    }
	    default {
		error "uname setting $what not implemented"
	    }
	}
	set unameCache($what) $result
    }
    
    return $unameCache($what)
}

########################################################################
# internal module procedures

proc getPathToModule {mod} {
    global env g_currentModule g_loadedModulesGeneric

    if [info exists env(MODULEPATH)] {
	foreach dir [split $env(MODULEPATH) ":"] {
	    set path "$dir/$mod"
	    if [file exists $path] {
		if [file readable $path] {
		    if [file isdirectory $path] {
			if [info exists g_loadedModulesGeneric($mod)] {
			    set ModulesVersion $g_loadedModulesGeneric($mod)
			} elseif [file exists "$path/.version"] {
			    source "$path/.version"
			} else {
			    set ModulesVersion [file tail [lindex [glob "$path/*"] 0]]
			}
			set path "$path/$ModulesVersion"
			set mod "$mod/$ModulesVersion"
		    }
		    
		    if [file isfile $path] {
			set g_currentModule $mod
			return $path
		    }
		} else {
		    error "$path not readable"
		}
	    }
	}
	error "Module $mod not found on \$MODULEPATH.\nHINT: Use 'module use ...' to add to search path."
    } else {
	error "\$MODULEPATH not defined"
    }
}

proc renderSettings {} {
    global g_newEnvVars g_newAliases g_shellType g_shell
    global g_delEnvVars g_delAliases
    global g_newXResources g_delXResources

    set iattempt 0
    set f ""
    while {$iattempt < 100 && $f == ""} {
	set tmpfile [format "/tmp/modulescript_%d_%d" [pid] $iattempt]
	set f [open  $tmpfile "w"]
	incr iattempt
    }
    
    if {$f == ""} {
	error "Could not open a temporary file in /tmp/modulescript_* !"
    } else {
	switch $g_shellType {
	    csh {
		foreach var [array names g_newEnvVars] {
		    set val [doubleQuoteEscaped $g_newEnvVars($var)]
		    puts $f "setenv $var \"$val\""
		}
		foreach var [array names g_newAliases] {
		    set val [doubleQuoteEscaped $g_newAliases($var)]
		    puts $f "alias $var \"$val\""
		}
		foreach var [array names g_delEnvVars] {
		    puts $f "unsetenv $var"
		}
		foreach var [array names g_delAliases] {
		    puts $f "unalias $var"
		}
		if {[array size g_newXResources] > 0} {
		    foreach var [array names g_newXResources] {
			set val $g_newXResources($var)
			if {$val == "_FILE_"} {
			    puts $f "xrdb -merge $var"
			} else {
			    puts $f "xrdb -merge <<EOF"
			    puts $f "$var: $val"
			    puts $f "EOF"
			}
		    }
		}
		if {[array size g_delXResources] > 0} {
		    foreach var [array names g_delXResources] {
			if {$val == "_FILE_"} {
			    # do nothing
			} else {
			    puts $f "xrdb -remove <<EOF"
			    puts $f "$var:"
			    puts $f "EOF"
			}
		    }
		}
		puts $f "/bin/rm -f $tmpfile"
	    }
	    sh {
		foreach var [array names g_newEnvVars] {
		    set val [doubleQuoteEscaped $g_newEnvVars($var)]
		    puts $f "$var=\"$val\"; export $var"
		}
		foreach var [array names g_newAliases] {
		    set val $g_newAliases($var)
		    puts $f "$var () {\n$val\n}"
		}
		foreach var [array names g_delEnvVars] {
		    puts $f "unset $var"
		}
		if {$g_shell == "zsh"} {
		    foreach var [array names g_delAliases] {
			puts $f "unfunction $var"
		    }
		} else {
		    foreach var [array names g_delAliases] {
			puts $f "unset $var"
		    }
		}
		if {[array size g_newXResources] > 0} {
		    foreach var [array names g_newXResources] {
			set val $g_newXResources($var)
			if {$val == "_FILE_"} {
			    puts $f "xrdb -merge $var"
			} else {
			    puts $f "xrdb -merge <<EOF"
			    puts $f "$var: $val"
			    puts $f "EOF"
			}
		    }
		}
		if {[array size g_delXResources] > 0} {
		    foreach var [array names g_delXResources] {
			if {$val == "_FILE_"} {
			    # do nothing
			} else {
			    puts $f "xrdb -remove <<EOF"
			    puts $f "$var:"
			    puts $f "EOF"
			}
		    }
		}
		puts $f "/bin/rm -f $tmpfile"
	    }
	    perl {
		foreach var [array names g_newEnvVars] {
		    set val [doubleQuoteEscaped $g_newEnvVars($var)]
		    puts $f "\$ENV{$var}=\"$val\";"
		}
		foreach var [array names g_delEnvVars] {
		    puts $f "delete \$ENV{$var};"
		}
		puts $f "unlink(\"$tmpfile\");"
	    }
	    default {
		error "shell $g_shellType not implemented"
	    }
	}
	close $f
	switch $g_shellType {
	    csh {
		puts "source $tmpfile"
	    }
	    sh {
		puts ". $tmpfile"
	    }
	    perl {
		puts "do \"$tmpfile\";"
	    }
	}
    }
}

proc cacheCurrentModules {} {
    global g_loadedModules g_loadedModulesGeneric env

# mark specific as well as generic modules as loaded
    if [info exists env(LOADEDMODULES)] {
	foreach mod [split $env(LOADEDMODULES) ":"] {
	    set g_loadedModules($mod) 1
	    set g_loadedModulesGeneric([file dirname $mod]) [file tail $mod]
	}
    }
}

proc spaceEscaped {text} {
    regsub -all " " $text "\\ " text
    return $text
}

proc doubleQuoteEscaped {text} {
    regsub -all "\"" $text "\\\"" text
    return $text
}

########################################################################
# command line commands

proc cmdModuleList {} {
    global g_mode
    set g_mode "display"

    global env
    if [info exists env(LOADEDMODULES)] {
	set list [split $env(LOADEDMODULES) ":"]
	set max 0
	foreach mod $list {
	    if {[string length $mod] > $max} {
		set max [string length $mod]
	    }
	}
# save room for numbers and spacing: 2 digits + ) + space
	incr max 4
	set cols [expr int(80/$max)]
	set lines [expr int(([llength $list] -1)/ $cols) +1]

	for {set i 0} { $i < $lines} {incr i} {
	    for {set col 0} {$col < $cols } { incr col} {
		set index [expr $col * $lines + $i]
		set mod [lindex $list $index]
		if {$mod != ""} {
		    set mod [format "%2d) %-${max}s" $index $mod]
		    puts -nonewline stderr $mod
		}
	    }
	    puts stderr ""
	}
    }
}

proc cmdModuleDisplay {mod} {
    global g_mode env tcl_version

    set g_mode "display"
    catch {
	set modfile [getPathToModule $mod]
	puts stderr "-------------------------------------------------------------------"
	puts stderr "$modfile:\n"
	source $modfile
	puts stderr "-------------------------------------------------------------------"
	set junk ""
    } errMsg
    if {$errMsg != ""} {
	puts stderr "ERROR: module display $mod failed. $errMsg"
    }
}

proc cmdModuleSwitch {old {new {}}} {
    if {$new == ""} {
	set new $old
	if {[file dirname $old] != "."} {
	    set old [file dirname $old]
	}
    }

    cmdModuleUnload $old
    cmdModuleLoad $new
}

proc cmdModuleLoad {args} {
    global g_mode g_currentModule env tcl_version g_loadedModules g_loadedModulesGeneric
 
    foreach mod $args {
	catch {
	    set modfile [getPathToModule $mod]
	    set currentModule $g_currentModule
	    set g_mode "load"
	    source $modfile
	    if { ! [ info exists g_loadedModules($currentModule)]} {
		append-path LOADEDMODULES $currentModule
		set g_loadedModules($currentModule) 1
		set g_loadedModulesGeneric([file dirname $mod]) [file tail $currentModule]
	    }
	    set junk ""
	} errMsg
	
        if {$errMsg != ""} {
	    puts stderr "ERROR: module load $mod failed. $errMsg"
	}
    }
}

proc cmdModuleUnload {args} {
    global g_mode g_currentModule env tcl_version g_loadedModules g_loadedModulesGeneric
 
    foreach mod $args {
	catch {
	    set modfile [getPathToModule $mod]
	    set currentModule $g_currentModule
	    if [ info exists g_loadedModules($currentModule)] {
		set g_mode "unload"
		source $modfile
		unload-path LOADEDMODULES $currentModule
		unset g_loadedModules($currentModule)
		if [info exists g_loadedModulesGeneric([file dirname $currentModule])] {
		    unset g_loadedModulesGeneric([file dirname $currentModule])
		}
	    }
	    set junk ""
	} errMsg
	if {$errMsg != ""} {
	    puts stderr "ERROR: module unload $mod failed. $errMsg"
	}
    }
}


proc cmdModulePurge {} {
    global env
    
    if [info exists env(LOADEDMODULES)] {
	set list [split $env(LOADEDMODULES) ":"] 
	eval cmdModuleUnload $list
    }
}


proc cmdModuleAvail { {mod {}}} {
    global g_mode env ignoreDir
    set g_mode "display"


    if {$mod == ""} {
	set mod  "*"
    }
    foreach dir [split $env(MODULEPATH) ":"] {
	if [file isdirectory $dir] {
	    array set availHash {}
	    puts stderr "---- $dir ---- "
	    cd $dir
 	    foreach file [glob -nocomplain "$mod/*"] {
		if { ! [info exists ignoreDir([file tail $file])]} {
		    # 		    puts stderr $file
		    set availHash($file) 1
		}
		#		if [file isfile $dir] {
		#		}
	    }
	    foreach mod2 [lsort [array names availHash]] {
		puts stderr $mod2
	    }
	}
    }
}

proc cmdModuleUse {args} {
    global g_mode
    set g_mode "load"
    foreach path $args {
	if [file isdirectory $path] {
	    prepend-path MODULEPATH $path
	} else {
	    error "Directory $path does not exist"
	}
    }
}

########################################################################
# main program

global g_shellType

set g_shell [lindex $argv 0]
set command [lindex $argv 1]
set argv [lreplace $argv 0 1] 
switch -regexp $g_shell {
    ^(sh|bash|ksh|zsh)$ {
	set g_shellType sh
    }
    ^(csh|tcsh)$ {
	set g_shellType csh
    }
    ^(perl)$ {
	set g_shellType perl
    }
    . {
	error "bad shell $g_shell"
    }
}

cacheCurrentModules

catch {
    switch $command {
	avail {
	    if {$argv != ""} {
		foreach arg $argv {
		    cmdModuleAvail $arg
		}
	    } else {
		cmdModuleAvail
	    }
	}
	list {
	cmdModuleList
	}
	display {
	    foreach arg $argv {
		cmdModuleDisplay $arg
	    }
	}
	load {
	    eval cmdModuleLoad $argv
	    renderSettings
	}
	purge {
	    cmdModulePurge
	    renderSettings
	}
	switch {
	    eval cmdModuleSwitch $argv
	    renderSettings
	}
	unload {
	    eval cmdModuleUnload $argv
	    renderSettings
	}
	use {
	    eval cmdModuleUse $argv
	    renderSettings
	}
	default {
	    puts stderr {
		ModulesTcl 0.9 (Copyright MIPS Technologies 2002):
		Available Commands and Usage:
		+ add|load              modulefile [modulefile ...]
		+ rm|unload             modulefile [modulefile ...]
		+ switch|swap           modulefile1 modulefile2
		+ display|show          modulefile [modulefile ...]
		+ avail                 [modulefile [modulefile ...]]
		+ use [-a|--append]     dir [dir ...]
		+ unuse                 dir [dir ...]
		+ update
		+ purge
		+ list
		+ clear
		+ help                  [modulefile [modulefile ...]]
		+ whatis                [modulefile [modulefile ...]]
		+ apropos|keyword       string
	    }
	}
	
    }
} errMsg

if {$errMsg != ""} {
    puts stderr "FINAL ERROR: $errMsg"
}


 

Re: [Modules] general RC files question

[R.K. O. Ph.D. <rk...@Ow...>]

Hi Harlan:
You could put in code, to the effect (csh) in /etc/csh.login
and the comparable code for /etc/profile, etc.

	if ( -f $HOME/.modules ) then
		source $HOME/.modules
	endif

(BTW - your earlier xterm question - need to add "-ls" for a login shell
to have the .login/.profile sourced and hence to have the modules env
set up.)

In the modules/etc/ dir is a add.modules script for adding the
necessary code to the user dot files to enable a modules environment.
It can be called multiple times (strip out the old code and insert
the new code).
The history of this is that I work for a user services group, which has
no system privileges, and it was easier to get a drink of water from a
Vogon than to have the security-retentive systems group modify the
/etc/rc files or to grant us access to do so.  Therefore, we had to
burdened our users with the task of running the add.modules script so
they could have access to modules.

The modules/ext/ dir represents our balance between the users & systems
groups. (The more retentive staff members are gone.)
The "ext" model is that the user dot files are symbolic
links to a common set of dot files that are maintained by the
user services group.  These dot files check for the existence
of $HOME/.login.ext, etc. and then source the users' customizations.
The add.modules in ext/ reflects this reality.  I think this latter
model works the best for us; the systems, user services, and the users.

 .modules was added fairly recently (3.1.0), so the documents don't say too
much about them ... please add as needed especially given your current
experience adding it to your systems.

	R.K.
+------------------+---------------------+
| R.K.Owen,PhD     | rk...@ow...    |
| KooZ Software    | Environment Modules |
| NERSC/LBNL       | rk...@ne...    |
+------------------+---------------------+

On Fri, 25 Oct 2002, Harlan Stenn wrote:

> OK, I just discovered that the ~/.modules file is part of the EXT stuff.
> 
> Time to do more reading...
> 
> H
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future 
> of Java(TM) technology. Join the Java Community 
> Process(SM) (JCP(SM)) program now. 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
>