modules-interest — Discussion forum for modules usage.

Re: [Modules] Modules and Tcl/Tk 8.4

[Peter W. O. <pw...@In...>]

> *** Mark Lakata <la...@mi...>
> *** [2002-09-18 10:47:49]:
> I don't think anyone uses anything but the core TCL stuff. 

well, we _do_ use numerous functions from the TclX library (we still
use modules 2.x with Tcl 6.x), I still have to check whether these
functions are now also available in the core Tcl (8.x) library.

	--pwo


[Slogan of the moment]
>>>>> And Now For Something Completely Different ...

Meeting, n.:
	An assembly of people coming together to decide what person or
	department not represented in the room must solve a problem.


--
Peter W. Osel                   Principal - Development Systems
Infineon Technologies           Email: pw...@In...
North America Corp.             Phone: +1 (408) 501 6321
1730 North First Street         Fax:   +1 (408) 501 2410
San Jose, CA 95112, USA         WWW:   http://pwo.de/

pgp key fingerprint = 79 2D DD 49 C0 AA D8 CF  2C F9 A5 6A BA 37 0E 28

Re: [Modules] Modules and Tcl/Tk 8.4

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

I don't think anyone uses anything but the core TCL stuff. 

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

On Wed, 18 Sep 2002, Gintautas Grigelionis wrote:

> Now that Tcl/Tk 8.4 is released, would someone clarify whether modules
> make use of any add-ons (plus-patch/TclX), and, if the answer to the
> first question is yes, is modules (3.2?) going to rely on core Tcl/Tk
> only, since the development of the abovementioned add-ons is pretty
> much nonexistent (TclX made it to sourceforge a couple of years ago
> and have yet to release some code).
> 
> Thanks in advance,
> 
> Gintas
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: AMD - Your access to the experts
> on Hammer Technology! Open Source & Linux Developers, register now
> for the AMD Developer Symposium. Code: EX8664
> http://www.developwithamd.com/developerlab
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
> 

[Modules] Modules and Tcl/Tk 8.4

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

Now that Tcl/Tk 8.4 is released, would someone clarify whether modules
make use of any add-ons (plus-patch/TclX), and, if the answer to the
first question is yes, is modules (3.2?) going to rely on core Tcl/Tk
only, since the development of the abovementioned add-ons is pretty
much nonexistent (TclX made it to sourceforge a couple of years ago
and have yet to release some code).

Thanks in advance,

Gintas

Re: [Modules] $HOME/.modules

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

Do you have something like this in .login or in the /etc/ startup files?
(And a comparable fragment for your .profile?)

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

The purpose of the .modules file is to allow your initadd changes to apply
to all csh/sh(& derivatives) shells.
However, you must source it to have it take effect.

Good luck,
	R.K.

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

On Tue, 17 Sep 2002, Fredrik Pettersson A (QRA) wrote:

> I can't get the modules added with module initadd to load. I use a $HOME/.modules as i cant user my .cshrc
> I can use module initadd, initlist... but when i login och start a shell no modules are loaded.
> Were do i start looking for faults?
> regards
> /Fredrik
> 

[Modules] $HOME/.modules

[Fredrik P. A (QRA) <Fre...@er...>]

I can't get the modules added with module initadd to load. I use a $HOME/.modules as i cant user my .cshrc
I can use module initadd, initlist... but when i login och start a shell no modules are loaded.
Were do i start looking for faults?
regards
/Fredrik

Re: [Modules] config mgt issues for modulefile names

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

My apologies, I guess I stepped in "it" this time.  Harlan has been very 
active on the modules-devel list, and I thought this was related to
the recent code base.  Read twice, respond once. Enuf said.

When I have a package I want modules to handle, I install things in
/usr/local/pkg/foo/1.2 or something similar.  (It could be /opt
just as well.  Then I create a modulefile e.g.
/usr/local/Modules/modulefiles/foo/1.2 , setting the .version, etc.
and I define a symbolic link in /usr/local/pkg/foo, "ln -s 1.2 default"
if it's something I need to call from an rc or init.d type scripts and 
I'll probably forget to edit the script if I place a specific version.

I eschewed the /usr/local/pkg/foo_1.2 convention (which is used quite
abit at my employer - NERSC) because this results in an overfull
and confusing /usr/local/pkg dir.  I find the rest of the staff has a
reluctance to making numerical named directories, however.
It could be taken a step further with .../foo/1/2 directories, but
this often overkill.

For local patches. I do the vain thing and add my initials and maybe
a number if I apply more than 1 set of my own patches in the package
lifetime.  (Recall the early modules-3.0.6-rko.)
At least I know that the naming convention won't conflict with the vendor
patch names and it identifies package sources I should tar ball for storage.
BTW, the untar'd sources are removed and only the tar ball is kept around,
with a collected README on what I did to build & install all the packages.

In a group, this might work well also, then it identifies the
package installer/maintainer.

However, if we polled every member of this list, I would wager that
everyone has their own unique way of doing things.  Anyways, this is
my unique way (which some of it has crept into the modules docs and
scripts ;^).

	R.K.

On Thu, 12 Sep 2002, David C. Mores wrote:

> Harlan Stenn wrote:
> 
> > R.K.,
> >
> > > How does this vary from the current numbering scheme?
> > > Where, say 3.1.6, the '6' represents a collection of minor changes,
> > > the patchlevel as it were.  The major/minor version is 3.1.
> > > Or do you propose a system such as 3.1.6pl2 (so something similar)?
> >
> > I'm talking about something else - I'm talking about the case where one
> > wants to identify/segregate sets of local changes to (in this case) 3rd
> > party software.
> >
> 
> The scheme we have been using for the past 10+ years involves 3 parts to the application mount point and 3 levels of modulefile area directory structure.  For example netscape 4.79 would be hosted in the directory tree netscape_4.79_a, where the postfix a is the local revision level.  This would result in modulefile path netscape/4.79/a where 'a' is the actual modulefile.  If a local revision is made, the directory tree would be cloned to netscape_4.79_b, local changes made and the associated modulefile
> path would be netscape/4.79/b.  This provides for a simple and controlled migration scheme that can be backed out quickly, if changes do not work out.  It also clearly keeps the identity of what version of the application is being used and indicates the level of local revisions.
> 
> Hope some of these ideas help you out.
> 
> Dave
> 
> 
> 
> -------------------------------------------------------
> 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
> 

Re: [Modules] config mgt issues for modulefile names

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

Harlan Stenn wrote:

> R.K.,
>
> > How does this vary from the current numbering scheme?
> > Where, say 3.1.6, the '6' represents a collection of minor changes,
> > the patchlevel as it were.  The major/minor version is 3.1.
> > Or do you propose a system such as 3.1.6pl2 (so something similar)?
>
> I'm talking about something else - I'm talking about the case where one
> wants to identify/segregate sets of local changes to (in this case) 3rd
> party software.
>

The scheme we have been using for the past 10+ years involves 3 parts to the application mount point and 3 levels of modulefile area directory structure.  For example netscape 4.79 would be hosted in the directory tree netscape_4.79_a, where the postfix a is the local revision level.  This would result in modulefile path netscape/4.79/a where 'a' is the actual modulefile.  If a local revision is made, the directory tree would be cloned to netscape_4.79_b, local changes made and the associated modulefile
path would be netscape/4.79/b.  This provides for a simple and controlled migration scheme that can be backed out quickly, if changes do not work out.  It also clearly keeps the identity of what version of the application is being used and indicates the level of local revisions.

Hope some of these ideas help you out.

Dave

Re: [Modules] config mgt issues for modulefile names

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

R.K.,

> How does this vary from the current numbering scheme?
> Where, say 3.1.6, the '6' represents a collection of minor changes,
> the patchlevel as it were.  The major/minor version is 3.1.
> Or do you propose a system such as 3.1.6pl2 (so something similar)?

I'm talking about something else - I'm talking about the case where one
wants to identify/segregate sets of local changes to (in this case) 3rd
party software.

Speaking of confusing, what's a good way to identify "things we deploy using
modules and modulefiles" and "things about modules and modulefiles"?

> Also, it might be a bit premature of talking about a release ... there
> are still quite a few things to do for the 3.2.x code.

I was talking about "how do I XXX using modules and modulefiles", not about
the actual modules codebase.

H

Re: [Modules] config mgt issues for modulefile names

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

Hello Harlan:
How does this vary from the current numbering scheme?
Where, say 3.1.6, the '6' represents a collection of minor changes,
the patchlevel as it were.  The major/minor version is 3.1.
Or do you propose a system such as 3.1.6pl2 (so something similar)?

Also, it might be a bit premature of talking about a release ... there
are still quite a few things to do for the 3.2.x code.

	R.K.

+------------------+---------------------+
| R.K.Owen,PhD     | rk...@ow...    |
| KooZ Software    | Environment Modules |
| NERSC/LBNL       | rk...@ne...    |
+------------------+---------------------+
On Tue, 10 Sep 2002, Harlan Stenn wrote:

> For configuration management purposes I need to have every set of changes to
> a package available.
> 
> I'm trying to figure out a good way to handle the naming issues and
> reasonably track the patches.
> 
> For example, I'll install foo/1.0 as a stock package.  Time passes, and
> Somebody decides that we must make some changes to the code base.
> 
> I generally use the BSD ports paradigm for building software (very similar
> ot the mpkg format), so I have a foo/1.0/Makefile that grabs the source
> tarball and builds/installs it in a modules-aware way, using foo/1.0 as the
> modulefile name.
> 
> For the first patch set of foo-1.0 I copy foo/1.0/* to, say, foo/1.0-1, and
> add foo/1.0-1/patches/ which contains the patches to the stock sources to
> give me my first revision of patches.
> 
> I can build/install this using foo/1.0-1 as the modulefile.
> 
> What I don't have strong opinions on are the issues surrounding "What do I
> call it":
> 
> - what's a good way to separate the package version number from the
>   "revision" tag:
> - - 1.0-1
> - - 1.0--1	# packages rarely use -- as a separator... 
> - - 1.0,1
> - - ????
> 
> What other issues might be significant?
> 
> I'm already planning to update the "version" info in each "revised" package
> so I can see which one is being used.
> 
> H
> 
> 
> 
> -------------------------------------------------------
> In remembrance
> www.osdn.com/911/
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
> 

RE: [Modules] config mgt issues for modulefile names

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

Harlan Stenn (Har...@pf...) wrote:

> [snip]
> For the first patch set of foo-1.0 I copy foo/1.0/* to, say, 
> foo/1.0-1, and add foo/1.0-1/patches/ which contains the
> patches to the stock sources to give me my first revision
> of patches.
> 
> I can build/install this using foo/1.0-1 as the modulefile.
> 
> What I don't have strong opinions on are the issues 
> surrounding "What do I call it":
> 
> - what's a good way to separate the package version number from the
>   "revision" tag:
> - - 1.0-1
> - - 1.0--1	# packages rarely use -- as a separator... 
> - - 1.0,1
> - - ????
> 
> What other issues might be significant?
> 
> I'm already planning to update the "version" info in each 
> "revised" package so I can see which one is being used.

There's almost no way to avoid a conflict at some point.
EDA vendors do whatever the heck they feel like, so we
go with their versioning scheme (and we don't have to
rebuild the programs) so that's fine.  But internally
created code and/or open source programs that you modify
are a different matter.

We've chosen to use lower-case letters in most cases.
Since most programs use "dot number" versioning, it
has done a reasonable job of self-documentation that
this is a in-house modification or a special version.
Still, it's not general-purpose, so not ideal for your
configuration management needs.

But using "--" might be problematic; dashes have given
me fits when trying to use a value contained in a shell
or env var in a script.  Too often they get interpreted
instead of passed directly as you intended.  Perhaps this
is totally not an issue for you, but in our modulefiles
we do set an environment var for the tool version loaded
and I make use of them in various scripts.

- Leo

Re: [Modules] config mgt issues for modulefile names

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

Thanks!

I'll take that as a vote for "PKG/VER--LOCALREV", the '--' as separator.

And sometimes I use an increasing number for the local revision, and
sometimes I use a [YY]YYMMDD local revision tag.

H

Re: [Modules] config mgt issues for modulefile names

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

good luck. I don't think there is any agreement out there on how to name
patches. To your list, I would add things like this (these are all actual names
of modules around here, based on the vendor's naming "convention").

 1.0-hotfix
 1.0p1
 1.0-A6-2
 1.0-beta
 1.0-SP2
 1.0-neil
 1.0-20020105
 1.0QSR3
 1.0a
 1.0.0.0.1.0.0

My advice is to stick to the vendor names. If there is no vendor name (ie some
random patch on open source code), then a date-stamp (like 20020910, ie
YYYYMMDD) is useful.



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

On Tue, 10 Sep 2002, Harlan Stenn wrote:

> For configuration management purposes I need to have every set of changes to
> a package available.
> 
> I'm trying to figure out a good way to handle the naming issues and
> reasonably track the patches.
> 
> For example, I'll install foo/1.0 as a stock package.  Time passes, and
> Somebody decides that we must make some changes to the code base.
> 
> I generally use the BSD ports paradigm for building software (very similar
> ot the mpkg format), so I have a foo/1.0/Makefile that grabs the source
> tarball and builds/installs it in a modules-aware way, using foo/1.0 as the
> modulefile name.
> 
> For the first patch set of foo-1.0 I copy foo/1.0/* to, say, foo/1.0-1, and
> add foo/1.0-1/patches/ which contains the patches to the stock sources to
> give me my first revision of patches.
> 
> I can build/install this using foo/1.0-1 as the modulefile.
> 
> What I don't have strong opinions on are the issues surrounding "What do I
> call it":
> 
> - what's a good way to separate the package version number from the
>   "revision" tag:
> - - 1.0-1
> - - 1.0--1	# packages rarely use -- as a separator... 
> - - 1.0,1
> - - ????
> 
> What other issues might be significant?
> 
> I'm already planning to update the "version" info in each "revised" package
> so I can see which one is being used.
> 
> H
> 
> 
> 
> -------------------------------------------------------
> In remembrance
> www.osdn.com/911/
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
> 

[Modules] config mgt issues for modulefile names

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

For configuration management purposes I need to have every set of changes to
a package available.

I'm trying to figure out a good way to handle the naming issues and
reasonably track the patches.

For example, I'll install foo/1.0 as a stock package.  Time passes, and
Somebody decides that we must make some changes to the code base.

I generally use the BSD ports paradigm for building software (very similar
ot the mpkg format), so I have a foo/1.0/Makefile that grabs the source
tarball and builds/installs it in a modules-aware way, using foo/1.0 as the
modulefile name.

For the first patch set of foo-1.0 I copy foo/1.0/* to, say, foo/1.0-1, and
add foo/1.0-1/patches/ which contains the patches to the stock sources to
give me my first revision of patches.

I can build/install this using foo/1.0-1 as the modulefile.

What I don't have strong opinions on are the issues surrounding "What do I
call it":

- what's a good way to separate the package version number from the
  "revision" tag:
- - 1.0-1
- - 1.0--1	# packages rarely use -- as a separator... 
- - 1.0,1
- - ????

What other issues might be significant?

I'm already planning to update the "version" info in each "revised" package
so I can see which one is being used.

H

[Modules] Patch to modules

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

Here's an updated resend of my previous patches.

I'd submit them via my sf login account, but that's hard to do from wy work
account.

Part of the patch to Makefile.am is a bugfix - libraries are built in the
build directory, not the source directory.

Whoever added "skipping RCS and CVS directories" didn't include SCCS as
well.

Finally, my collate algorithm alternative is provided again.

Thanks for converting to automake - I had these patches waiting to go out
and then I got busy.  Somebody beat me to it.

I think the RUNTEST check at the end of configure.ac may be a lose -
current versions of autoconf and automake seem to overlook the "dejagnu"
that exists in AUTOMAKE_OPTIONS and therefore die.

Finally, how about losing the auto* generated files from the repo?
Especially lib/Makefile ...

H

Re: [Modules] Using modules on multiple platform at the same time

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

Laurent Besson wrote:

 > [snip]
> In my .cshrc, I'm doing a "module update" if $LOADEDMODULES is not
 > empty.  AND I ended up with SUN path in my LINUX box.
> 
> The problem lies in the .modulesbeginenv file which is written when
 > a shell starts. So, first, I run a shell on Linux, then another one
 > on Sun and then come back to my Linux terminal and type 'module
 > update'. At this time, Modules unload my currently loaded modules,
 > read the .modulesbeginenv (which has been re-written by the Sun
 > shell) and re-load the modules.
> 
> To solve this problem, I thought on using the _MODULESBEGINENV_
 > variable but this does not work proprely as the code in modules
 > does not update its content upon startup.
> 
> So, instead of using "module update", I'm doing this in my .cshrc
> 
> [snip]

Hello, Laurent.

The .modulesbeginenv is problematic in a heterogeneous environment
that shares user home directories.  In my company's situation, we
never used the "update" command, just as a matter of how I used
modules and therefore trained everyone else to use it.  When we
login to either our Solaris or Linux boxen, our environment is set
fresh based upon what we've selected to load in our .cshrc.  We
just don't use "update" at all.

Our platform-specific variations are handled in our modulefiles,
as another person on the reflector described.  If a tool isn't
available on Linux, the module shows that it's loaded but it
doesn't really do anything.  It might seem "unclean", but it hasn't
caused us any real issues.

Every shop seems to have its own set of problems due to site-specific
implementations of multiple architectures; mistakes or "features"
in the implementation tend to not be resolved quickly.  We often
end up changing how we do things, and this may be one of those cases
for you.  While we could likely fix the .modulesbeginenv issue in a
future release, it's probably not so useful a feature to depend upon
that.

In our environment, we have some code set up in our .cshrc to unsetenv
all of the modules-related environment variables, so we can get back
to our default setup by simply re-sourcing our .cshrc.  I had done
this when we were a mostly Sun-only shop, and it worked on Linux
right out of the shute.  If you'd like to see the code, let me know.

I hope this helps!

Regards,

- Leo Butler

Re: [Modules] Using modules on multiple platform at the same time

[Laurent B. <lau...@st...>]

Hi Jon,

Thank you for sharing your experience on multi-platform modules env.

Maybe I'va not been clear in my mail.

My problem comes from "module update" where the .modulesbeginenv file
has been re-written by the other platform in the mean time.

Laurent.


jtu...@lu... wrote:

> Laurent,
> 
> We have what looks like a similar environment here, with Solaris & Linux.
> In my .cshrc file, This is all I have to distinguish between the 2:
> 
> 
>>setenv MODULESHOME /tools/contrib
>>setenv MODULEPATH
>>${HOME}/mf:${MODULESHOME}/modulefiles:${MODULESHOME}/projects
>>
> 
>>if ( `uname` == "Linux") then
>> alias module 'eval `/tools/contrib/linux-bin/bin/modulecmd tcsh \!*`'
>>else
>> alias module 'eval `/usr/local/bin/modulecmd tcsh \!*`'
>>endif
>>
> 
>>unset autologout
>>unsetenv _LMFILES_
>>unsetenv LOADEDMODULES
>>
> 
> Then, each modulefile has a 'case' statement:
> 
> case [uname release] in {
> 
>  5.* {
>    SOLARIS STUFF
>   }
> 
>  2.* {
>    LINUX STUFF
>   }
> }
> 
> Hope this helps...
> 
> Jon
> 
> On Wed, 4 Sep 2002, Laurent Besson wrote:
> 
> 
>>Hi All,
>>
>>Until recently, I was a happy user of Modules and everything was fine.
>>
>>Few weeks ago, my company bought some Linux boxes and the troubles begin.
>>Let me explain a little bit more.
>>
>>Traditionnaly, I was working on SUN workstation (under Solaris 2.7 or 2.8).
>>With the new linux boxes, I had to modify my "modules" scripts to define
>>different PATHS based on the "uname" return value. No problem.
>>
>>In my .cshrc, I'm doing a "module update" if $LOADEDMODULES is not empty.
>>AND I ended up with SUN path in my LINUX box.
>>
>>The problem lies in the .modulesbeginenv file which is written when a shell
>>starts. So, first, I run a shell on Linux, then another one on Sun and then
>>come back to my Linux terminal and type 'module update'. At this time, Modules
>>unload my currently loaded modules, read the .modulesbeginenv (which has been
>>re-written by the Sun shell) and re-load the modules.
>>
>>To solve this problem, I thought on using the _MODULESBEGINENV_ variable but this
>>does not work proprely as the code in modules does not update its content upon
>>startup.
>>
>>So, instead of using "module update", I'm doing this in my .cshrc
>>
>>if ($LOADEDMODULES != '') then
>>   set PREVIOUS_LOADEDMODULES = `echo $LOADEDMODULES |  tr ':' ' '`
>>   module purge
>>   module load $PREVIOUS_LOADEDMODULES
>>else
>>   module load home
>>   module load free
>>   # source /home/stv3000/setup_files/setup.cad.csh
>>   module add projects/3500
>>   # module add projects/2000
>>endif
>>
>>Has anybody a better idea on managing this ?
>>
>>Laurent.
>>
>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by: OSDN - Tired of that same old
>>cell phone?  Get a new here for FREE!
>>https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>>_______________________________________________
>>Modules-interest mailing list
>>Mod...@li...
>>https://lists.sourceforge.net/lists/listinfo/modules-interest
>>
>>
> 

Re: [Modules] Using modules on multiple platform at the same time

[Laurent B. <lau...@st...>]

You're right. This is what I tried when after readign the doc, I saw
the _MODULESBEGINENV_ env. variable.

Unfortunately, if you define such a variable, then "modules" no
longer write the startup environment in it and consider the file
as a setup file (and no more a place to save before-module env).

This is what is said in the comment in init.c, line  335

Laurent.

abo@e.kth.se wrote:

> Laurent Besson <lau...@st...> writes:
> 
> 
>>The problem lies in the .modulesbeginenv file which is written when a shell
>>starts. So, first, I run a shell on Linux, then another one on Sun and then
>>come back to my Linux terminal and type 'module update'. At this time, Modules
>>unload my currently loaded modules, read the .modulesbeginenv (which has been
>>re-written by the Sun shell) and re-load the modules.
>>
> 
> Why not use /tmp/.modulesbeginenv.$USER.$RANDOM instead?
> 
> /abo
> 

Re: [Modules] Using modules on multiple platform at the same time

[Alexander B. <abo@e.kth.se>]

Laurent Besson <lau...@st...> writes:

> The problem lies in the .modulesbeginenv file which is written when a shell
> starts. So, first, I run a shell on Linux, then another one on Sun and then
> come back to my Linux terminal and type 'module update'. At this time, Modules
> unload my currently loaded modules, read the .modulesbeginenv (which has been
> re-written by the Sun shell) and re-load the modules.

Why not use /tmp/.modulesbeginenv.$USER.$RANDOM instead?

/abo

Re: [Modules] Using modules on multiple platform at the same time

[Jonathan T. <jtu...@lu...>]

Laurent,

We have what looks like a similar environment here, with Solaris & Linux.
In my .cshrc file, This is all I have to distinguish between the 2:

>setenv MODULESHOME /tools/contrib
>setenv MODULEPATH
>${HOME}/mf:${MODULESHOME}/modulefiles:${MODULESHOME}/projects

>if ( `uname` == "Linux") then
>  alias module 'eval `/tools/contrib/linux-bin/bin/modulecmd tcsh \!*`'
>else
>  alias module 'eval `/usr/local/bin/modulecmd tcsh \!*`'
>endif

>unset autologout
>unsetenv _LMFILES_
>unsetenv LOADEDMODULES

Then, each modulefile has a 'case' statement:

case [uname release] in {

 5.* {
   SOLARIS STUFF
  }

 2.* {
   LINUX STUFF
  }
}

Hope this helps...

Jon

On Wed, 4 Sep 2002, Laurent Besson wrote:

> Hi All,
>
> Until recently, I was a happy user of Modules and everything was fine.
>
> Few weeks ago, my company bought some Linux boxes and the troubles begin.
> Let me explain a little bit more.
>
> Traditionnaly, I was working on SUN workstation (under Solaris 2.7 or 2.8).
> With the new linux boxes, I had to modify my "modules" scripts to define
> different PATHS based on the "uname" return value. No problem.
>
> In my .cshrc, I'm doing a "module update" if $LOADEDMODULES is not empty.
> AND I ended up with SUN path in my LINUX box.
>
> The problem lies in the .modulesbeginenv file which is written when a shell
> starts. So, first, I run a shell on Linux, then another one on Sun and then
> come back to my Linux terminal and type 'module update'. At this time, Modules
> unload my currently loaded modules, read the .modulesbeginenv (which has been
> re-written by the Sun shell) and re-load the modules.
>
> To solve this problem, I thought on using the _MODULESBEGINENV_ variable but this
> does not work proprely as the code in modules does not update its content upon
> startup.
>
> So, instead of using "module update", I'm doing this in my .cshrc
>
> if ($LOADEDMODULES != '') then
>    set PREVIOUS_LOADEDMODULES = `echo $LOADEDMODULES |  tr ':' ' '`
>    module purge
>    module load $PREVIOUS_LOADEDMODULES
> else
>    module load home
>    module load free
>    # source /home/stv3000/setup_files/setup.cad.csh
>    module add projects/3500
>    # module add projects/2000
> endif
>
> Has anybody a better idea on managing this ?
>
> Laurent.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
>

[Modules] Using modules on multiple platform at the same time

[Laurent B. <lau...@st...>]

Hi All,

Until recently, I was a happy user of Modules and everything was fine.

Few weeks ago, my company bought some Linux boxes and the troubles begin.
Let me explain a little bit more.

Traditionnaly, I was working on SUN workstation (under Solaris 2.7 or 2.8).
With the new linux boxes, I had to modify my "modules" scripts to define
different PATHS based on the "uname" return value. No problem.

In my .cshrc, I'm doing a "module update" if $LOADEDMODULES is not empty.
AND I ended up with SUN path in my LINUX box.

The problem lies in the .modulesbeginenv file which is written when a shell
starts. So, first, I run a shell on Linux, then another one on Sun and then
come back to my Linux terminal and type 'module update'. At this time, Modules
unload my currently loaded modules, read the .modulesbeginenv (which has been
re-written by the Sun shell) and re-load the modules.

To solve this problem, I thought on using the _MODULESBEGINENV_ variable but this
does not work proprely as the code in modules does not update its content upon
startup.

So, instead of using "module update", I'm doing this in my .cshrc

if ($LOADEDMODULES != '') then
   set PREVIOUS_LOADEDMODULES = `echo $LOADEDMODULES |  tr ':' ' '`
   module purge
   module load $PREVIOUS_LOADEDMODULES
else
   module load home
   module load free
   # source /home/stv3000/setup_files/setup.cad.csh
   module add projects/3500
   # module add projects/2000
endif

Has anybody a better idea on managing this ?

Laurent.

Re: [Modules] Special handling for PATH? I think not.

[<me...@cs...>]

In reply to Steven W. Orr (st...@sy...):

I just downloaded envv to take a look at it.
It seems the biggest difference is modules is packaged a little nicer for
users.

modules does the same sorts of things envv does however it also
provides a standard way to look at what configuration scripts are out
there and how to use them and see what they do.
(I could be wrong because I haven't used envv but from reading the man page
and looking at what I downloaded envv does not do things like:

module avail
module show (module)
module initadd (module)
module initremove (module)


Kent

RE: [Modules] Special handling for PATH? I think not.

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

Steven W. Orr (st...@sy...) wrote:

> On Thu, 15 Aug 2002, Mark Lakata wrote:
> 
> > It all boils down to the lameness of rsh. I think everyone 
> > solves this problem a different way, and none of them are
> > really good.
> > 
> > Here, the sysadmins have set it up so that ~/.cshrc 
> > automatically sources ~/.login. Basically this gets around
> > the rsh problem, but then you longer have the distinction
> > between .cshrc and .login. And you will notice that I am
> > using TCSH as my example, just to point out that this problem 
> > exists in all shells... 
> > 
> > I personally either avoid using rsh for anything general 
> > (it works ok for cvs), or create an elaborate 'expect' script
> > which does an rsh and then does an explicit 'module load foo
> > bar' to get the paths (I did this for a multi-OS SunOS/Linux/
> > HP build flow). We have paid big bucks for LSF (Load Sharing
> > Facility) for distributed computing...
> > 
> > -mark
> 
> I can't help myself. I just have to start a religios war. :-)
> 
> Is everyone here not completely aware that the Csh is *BAD*? 
> Dangerous?  Has everyone here not yet read "C shell considered
> harmful" by Tom Christianson? He outlines all of the evils of
> csh including the fact that upon login, you run the .cshrc
> *before* you run your .login.  My question had to do with
> running ksh/bash and using modules. The question is simple: 
> Does it mke sense for modules to be modified so that it would 
> produce a seperate .bash_path which would be distinct from the
> .bashrc and the .bash_profile, of should it be accomplished by
> how you comfigure a module in the first place.
> 
> I really am new to this, and what I've been using so far is a 
> program (it happens to be written in perl) called envv which is
> used simply for editing environment variables whose values are
> colon seperated lists. I'm actually trying to figure out (among
> other things) why modules is better my envv program.

Hello, Steven.

Yeah, csh has its warts and isn't nearly as portable as
sh/ksh/bash, but it's what most of us got set up with by
default on our *nix systems years and years ago.  Now we
have it deployed for everyone, and there are many other
battles to fight before I try to convert the entire group
to a new shell.

One nice thing about modules is that I wouldn't have to
rewrite one line of a modulefile to do that.  We can use
any shell we want, and the modulefiles will work in all
of them.  Cross-platform, too.  I've done a Perl script
that sounds a lot like yours a couple of years ago, and
while it worked it was not as portable or flexible as
modules.

Now as to your question about whether modules should do
the .bash_path thing, my thought is no -- you have
greater flexibility by doing it as you are now (or in
some modified manner once using modules).  We all have
legacy and usage models we must deal with, and to date
modules has remained flexible enough to accomodate most
of these different implementations.

I don't mean to be dismissive of your suggestion; it's
just my opinion in this instance.

Regards,

- Leo Butler

Re: [Modules] Special handling for PATH? I think not.

[Steven W. O. <st...@sy...>]

On Thu, 15 Aug 2002, Mark Lakata wrote:

=>It all boils down to the lameness of rsh. I think everyone solves this problem
=>a different way, and none of them are really good.
=>
=>Here, the sysadmins have set it up so that ~/.cshrc automatically sources
=>~/.login. Basically this gets around the rsh problem, but then you longer have
=>the distinction between .cshrc and .login. And you will notice that I am using
=>TCSH as my example, just to point out that this problem exists in all shells... 
=>
=>I personally either avoid using rsh for anything general (it works ok for cvs),
=>or create an elaborate 'expect' script which does an rsh and then does an
=>explicit 'module load foo bar' to get the paths (I did this for a multi-OS
=>SunOS/Linux/HP build flow). We have paid big bucks for LSF (Load Sharing
=>Facility) for distributed computing...
=>
=>-mark
I can't help myself. I just have to start a religios war. :-)

Is everyone here not completely aware that the Csh is *BAD*? Dangerous? 
Has everyone here not yet read "C shell considered harmful" by Tom 
Christianson? He outlines all of the evils of csh including the fact that 
upon login, you run the .cshrc *before* you run your .login. My question 
had to do with running ksh/bash and using modules. The question is simple: 
Does it mke sense for modules to be modified so that it would produce a 
seperate .bash_path which would be distinct from the .bashrc and the 
.bash_profile, of should it be accomplished by how you comfigure a module 
in the first place.

I really am new to this, and what I've been using so far is a program (it 
happens to be written in perl) called envv which is used simply for 
editing environment variables whose values are colon seperated lists. I'm 
actually trying to figure out (among other things) why modules is better 
than my envv program.

-- 
-Time flies like the wind. Fruit flies like a banana. Stranger things have -
-happened but none stranger than this. Does your driver's license say Organ
-Donor?Black holes are where God divided by zero. Listen to me! We are all-
-individuals! What if this weren't a hypothetical question? st...@sy...

Re: [Modules] Special handling for PATH? I think not.

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

It all boils down to the lameness of rsh. I think everyone solves this problem
a different way, and none of them are really good.

Here, the sysadmins have set it up so that ~/.cshrc automatically sources
~/.login. Basically this gets around the rsh problem, but then you longer have
the distinction between .cshrc and .login. And you will notice that I am using
TCSH as my example, just to point out that this problem exists in all shells... 

I personally either avoid using rsh for anything general (it works ok for cvs),
or create an elaborate 'expect' script which does an rsh and then does an
explicit 'module load foo bar' to get the paths (I did this for a multi-OS
SunOS/Linux/HP build flow). We have paid big bucks for LSF (Load Sharing
Facility) for distributed computing...

-mark



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

On Thu, 15 Aug 2002, Steven W. Orr wrote:

> I'm pretty new to modules, but I have a question/comment anyways:
> 
> I notice that in the docs it suggests that the PATH variable should be set 
> in your .bashrc instead of in your .bash_profile so that the PATH would 
> get set properly when you execute a remote command.
> 
> I have my .bashrc set up so that it checks if you are an interactive 
> process. 
> 
> If not, (as is the case when you are running a remote command) 
> then it sources a .bash_path I created which only defines PATH. It is 
> unconditionally sourced in by .bash_profile. Is this a change that wants 
> to go into modules or is this something to be addressed by the way I use 
> it?
> 
> Am I clear? Should I amplify?
> 
> if [ -z $PS1 ] # If true then not interactive
> then
> 	. ~/.bash_path
> 	... etc.
> 
> 
> -- 
> -Time flies like the wind. Fruit flies like a banana. Stranger things have -
> -happened but none stranger than this. Does your driver's license say Organ
> -Donor?Black holes are where God divided by zero. Listen to me! We are all-
> -individuals! What if this weren't a hypothetical question? st...@sy...
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
> 

[Modules] Special handling for PATH? I think not.

[Steven W. O. <st...@sy...>]

I'm pretty new to modules, but I have a question/comment anyways:

I notice that in the docs it suggests that the PATH variable should be set 
in your .bashrc instead of in your .bash_profile so that the PATH would 
get set properly when you execute a remote command.

I have my .bashrc set up so that it checks if you are an interactive 
process. 

If not, (as is the case when you are running a remote command) 
then it sources a .bash_path I created which only defines PATH. It is 
unconditionally sourced in by .bash_profile. Is this a change that wants 
to go into modules or is this something to be addressed by the way I use 
it?

Am I clear? Should I amplify?

if [ -z $PS1 ] # If true then not interactive
then
	. ~/.bash_path
	... etc.


-- 
-Time flies like the wind. Fruit flies like a banana. Stranger things have -
-happened but none stranger than this. Does your driver's license say Organ
-Donor?Black holes are where God divided by zero. Listen to me! We are all-
-individuals! What if this weren't a hypothetical question? st...@sy...