modules-interest — Discussion forum for modules usage.

Re: [Modules] LM_LICENSE_FILE/VENDOR_LICENSE_FILE

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

We do exactly the same thing. I'm not sure what your problem is though, it
seems straightforward.

a/abc : prepend-path VENDORA_LICENSE_FILE /vendor/a/lic/path
a/def : prepend-path VENDORA_LICENSE_FILE /vendor/a/lic/path
c/xyz : prepend-path LM_LICENSE_FILE /vendor/c/lic/path
d/qrs : prepend-path LM_LICENSE_FILE /vendor/d/lic/path

?



-Mark


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

On Tue, 9 Sep 2003 m.a...@co... wrote:

> Hi,
>
> We have multiple tools by multiple vendors.
> Our LM_LICENSE_FILE string required by all tools
> is too large for some vendors.  They supply a
> vendor specific string, e.g. VENDORA_LICENSE_FILE.
>
> The problem is when the vendor has two tools which
> we require, e.g. vendor_a/tool_abc and vendor_a/tool_def
> and we have other vendor's tools, vendor_c/tool_xyz
> and vendor_d/tool_qrs.
>
> I do not want each tool's contribution to LM_LICENSE_FILE
> to show up in VENDORA_LICENSE_FILE only the contribution
> from tool_abc and tool_def.
>
> Should I maintain environment variables for tool_abc
> and tool_def and use those to set VENDORA_LICENSE_FILE?
>
> I hope this is clear...
>
> Thanks,
> /Ed
>
>
> -------------------------------------------------------
> 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] LM_LICENSE_FILE/VENDOR_LICENSE_FILE

[<m.a...@co...>]

Hi,

We have multiple tools by multiple vendors.
Our LM_LICENSE_FILE string required by all tools
is too large for some vendors.  They supply a
vendor specific string, e.g. VENDORA_LICENSE_FILE.

The problem is when the vendor has two tools which
we require, e.g. vendor_a/tool_abc and vendor_a/tool_def
and we have other vendor's tools, vendor_c/tool_xyz
and vendor_d/tool_qrs.

I do not want each tool's contribution to LM_LICENSE_FILE
to show up in VENDORA_LICENSE_FILE only the contribution
from tool_abc and tool_def.

Should I maintain environment variables for tool_abc
and tool_def and use those to set VENDORA_LICENSE_FILE?

I hope this is clear...

Thanks,
/Ed

[Modules] Module switch bug

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

Hello R.K.,

The reflector has been quiet lately, but I wasn't looking
to break the silence with a bug report.  The following is
something I see in modules 3.1.6, but not in the Tcl version.

I see some incorrect behavior in a module switch in terms of
the order elements appear in an environment variable based
upon their order in the modulefile.  Consider two simple
modulefiles:

msw/a:
#%Module

append-path PATH a
append-path PATH b

msw/b:
#%Module

append-path PATH ax
append-path PATH bx

If I do a "module load" on msw/a, I get:

<other_part_of_path>:a:b

If I then do a "module switch msw msw/b", I get:

<other_part_of_path>:bx:ax

Note that the order is reversed from what it should be.

The workaround is to set a variable all at once, as in

append-path PATH a:b

but that's not, well, clean as we're hard-coding the colon
which I'd prefer to leave to modules to use as the record
separator.

This shows up as a problem when we put two paths in the
PATH variable, the first being the path to 64-bit executables
and the second the path to 32-bit executables.  When these
get swapped, we get the 32-bit versions and programs dump
with out-of-memory errors.  Unfortunately, some programs only
exist in the 32-bit directory so we need them both.

Regards,

- Leo

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

[Modules] Tracking with CVS?

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

I notice that if I commit a change to a file (:ext: access) that it takes
Time for that change to be visible if I try to update a repo on another
machine (using :pserver: access) even if I use the same Root.

Any idea what is going on here?

H

Re: [Modules] using stdout for module

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

I was not real surprised to discover that I can say:

 puts "echo 'foo';""

in a modulefile and the right thing seems to happen.

This implies I can do something similar in modulecmd.tcl (I'll try adding it
to renderSettings and then test it).

H

Re: [Modules] using stdout for module

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

good question. You can do this to capture stderr in csh or zsh:

 module avail |& less

or (in a bourne shell)

 module avail 2> availlist.txt



I tried playing around with the bourne shell, and got this nifty little
sequence to work. I'm not sure why it works, but it seems to. (I say this
because the 'eval' command seems to still distinguish between stdout (1) and
strderr (2), even though the "2>&1" command before them has somehow merged the
two.. ? a mystery.) Also, the man page for 'exec' doesn't explain what is going
on.


function module () {
        exec 3>& 2
        exec 2>& 1
        eval `/mips/tools/platinum/envmodule/modulecmd.tcl zsh $*`
        exec 2>& 3
}


If you define your module command this way, you can then output of module
appears to be from stdout, not stderr. Ie this works:

module avail > availlist.txt
module list | less


I'm not sure how to do this for csh variants.

-Mark





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

On Wed, 6 Aug 2003, Harlan Stenn wrote:

> I want to implement a new command or two:
>
>  module paths PGK   Returns the paths to the installed locations of each
> 		    version of PKG
>
>  module path PKG    Returns the path to the installed location of PKG
> 		    (the loaded, default, or highest version, as appropriate)
>
> The trick is that I want to use this in scripts.
>
> It is easier to get this information from stdout, but I know that since the
> "module" command (I'll be using modulecmd.tcl) does its work by sourcing in
> the information it needs, visible output is usually sent to stderr.
>
> Do I have to get my results from stderr, or is there a way to get it from
> stdout?
>
> I was thinking about emitting:
>
>  echo "OUTPUT";
>
> to stdout so when it is sourced the shell will execute the echo command (I'd
> use something else for perl or python "shells").
>
> Suggestions please...
>
> H
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
>

[Modules] using stdout for module

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

I want to implement a new command or two:

 module paths PGK   Returns the paths to the installed locations of each
		    version of PKG

 module path PKG    Returns the path to the installed location of PKG
		    (the loaded, default, or highest version, as appropriate)

The trick is that I want to use this in scripts.

It is easier to get this information from stdout, but I know that since the
"module" command (I'll be using modulecmd.tcl) does its work by sourcing in
the information it needs, visible output is usually sent to stderr.

Do I have to get my results from stderr, or is there a way to get it from
stdout?

I was thinking about emitting:

 echo "OUTPUT";

to stdout so when it is sourced the shell will execute the echo command (I'd
use something else for perl or python "shells").

Suggestions please...

H

[Modules] Modules mailing list archive updated

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

Greetings.

After just over a year wait, we've finally managed to get
the old mailing list archives from auburn.edu incorporated
into the Sourceforce mailarchive.  You can find things
dating back to 1996 here:

https://sourceforge.net/mailarchive/forum.php?forum_id=34594

Enjoy,

- Leo

Re: [Modules] modules 3.1.6 and placement of files

[Jeff S. <jsq...@la...>]

I faced all these same issues when I made the modules RPM for the OSCAR
Linux Cluster project (and made most of the same decisions you have
apparently made :-).  It's also under env-switcher.sf.net (I added a
persistent, two-level set of defaults on top of modules called
"env-switcher").  You can see my spec file at:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/env-switcher/modules-oscar/dist/modules-oscar.spec?rev=1.13&content-type=text/vnd.viewcvs-markup

Feel free to ask questions, etc.  That specfile is *mostly*
OSCAR-independant, but there is at least a few OSCAR-isms in there.

It's under a very BSD-ish license, so feel free to do with it as you wish.

Keep in mind that profile.d is *not* enough.  :-( (you would think that it
would be, but it isn't)  Some issues that you have to face:

1. Some (most?) Linux distros do not run profile.d for non-interactive
   remote shells (e.g., "ssh othernode uptime").

2. You need to ensure that the modules setup runs *first* in case other
   profile.d scripts use modules (which happens in OSCAR clusters).

I'm sorry I missed your first post, or I would have replied earlier.



On Fri, 27 Jun 2003, Erik Jacobson wrote:

> Hi there.  Thanks for this.
>
> First of all, after talking with some of my co-workers, I'm considering
> a different approach.  I'm considering installing under /opt, keeping the
> tree just like you would normally expect (see below).
>
> I'm thinking of changing the RPM spec file to be re-locatable.  If the
> user tries to relocate, I'm thinking to create an /etc/profile.d/modules.csh
> (and sh, etc) to set MODULESHOME.
>
> [root@morale tmp]# ls -l /opt/Modules
> total 0
> drwxr-xr-x    6 root     root           55 Jun 27 10:49 3.1.6
> lrwxrwxrwx    1 root     root            5 Jun 27 10:49 default -> 3.1.6
> drwxr-xr-x    2 root     root            6 Jun 27 07:43 modulefiles
> drwxr-xr-x    2 root     root           18 Jun 27 10:49 versions
>
>
> This would keep the modules setup more like it is 'out of the box' and give
> people some flexability if they still want to use rpm but locate the
> files elsewhere (ie /usr/local or whatever).
>
> Does this sound interesting or better?
>
> Thanks again for the suggestions.
>
> I'd be happy to send an example spec file if I pull this off.  I think I'm
> nearly done with it.
>
> On Fri, 27 Jun 2003, R.K. Owen Ph.D. wrote:
>
> > Hello Erik:
> > I'm the maintainer of the C version.  Your proposal for the modulecmd
> > in /usr/bin and user modules in /usr/share/Modules/ seems in keeping
> > with the intended purposes of those file directories.
> >
> > With the rpm mechanism, you're quite right in that there is no need
> > for the modules versioning system.  I created it to handle
> > modules development, which is less of an issue for rpms.
> >
> > However, I would propose that you keep the modulefiles which are included
> > in the modules distribution separate - /usr/share/Modules/module/modulefiles
> > with /usr/share/Modules/modulefiles for user defined ones.
> >
> > However, a large part of modules is the module alias.  How are you
> > instantiating the aliases in the /etc/ rc files?
> >
> > The current 3.1.6 line Makefile.in doesn't honor the DESTDIR env.var.
> > so I'm curious about your rpm spec file.  Are you just doing an installation
> > in place and then grabbing the rpm source files from the system?
> >
> > I've upgraded the 3.2.x sources to use automake, but the sources have
> > been heavily modified and not yet ready for distribution.  If you want
> > to back-port the 3.2.x Makefile.am and configure.ac to the 3.1.6 line
> > that would be useful, and it would handle most of the DESTDIR issues.
> >
> > I would be happy to include your changes into the 3.1.x line.
> >
> > 	R.K.
> > +------------------+---------------------+
> > | R.K.Owen,PhD     | rk...@ow...    |
> > | KooZ Software    | Environment Modules |
> > | NERSC/LBNL       | rk...@ne...    |
> > +------------------+---------------------+
> >
> > On Thu, 26 Jun 2003, Erik Jacobson wrote:
> >
> > > Hi there.
> > >
> > > I'm making an RPM of the modules package for ia64 redhat.  I have it working
> > > fine in a default sense.
> > >
> > > I've been trying to figure out the best placement of things for
> > > making this pre-packaged in an rpm.  I'm trying to keep both reality and the
> > > filesystem hierarchy standard in mind.
> > >
> > > I'm not sure that using /opt for the modules package is the best option
> > > since it isn't heavily used on a default installation of RedHat.
> > >
> > > /usr/local is supposed to be for local sysadmins (not for packaged
> > > software).  So I'll stay out of there.
> > >
> > > So I decided the best option would be to have the binaries go in to
> > > /usr/bin (modulecmd and such) since they are architecture specific and
> > > have the 3.1.6 module files, versions, and the default location for
> > > user-supplied modules be /usr/share/Modules/.
> > >
> > > The disadvantage of this seems to be that migrating to a new version of
> > > modules isn't done the same way.  This is true for many pre-packaged
> > > things so I'm not sure this is a reason not to do it.
> > >
> > > When playing with configure, I found that passing "--bindir" to configure
> > > properly installed the architecture dependent files in to /usr/bin as I
> > > told it to.  However, the shell init files couldn't find that path -
> > > apparently --bindir isn't used when constructing the init files from
> > > the .in files.
> > >
> > > I guess I have two questions:
> > >
> > >  - If I were to change modules to look at either --bindir or --exec-prefix
> > >    and properly adjust the init files accordingly, is it likely such a
> > >    change would be accepted by the authors assuming it doesn't break anything
> > >    that currently works?
> > >
> > >  - Do you have alternate suggestions on placement of the files?
> > >
> > > I guess if such a change to modules isn't interesting to the authors, I'd
> > > probably go with using /opt and not bother making changes myself to
> > > the modules package.
> > >
> > > --
> > > Erik Jacobson - Linux System Software - Silicon Graphics - Eagan, Minnesota
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by: INetU
> > > Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> > > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> > > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> > > _______________________________________________
> > > Modules-interest mailing list
> > > Mod...@li...
> > > https://lists.sourceforge.net/lists/listinfo/modules-interest
> > >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: INetU
> > Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> > _______________________________________________
> > Modules-interest mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modules-interest
> >
>
> --
> Erik Jacobson - Linux System Software - Silicon Graphics - Eagan, Minnesota
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
>

-- 
{+} Jeff Squyres
{+} jsq...@la...
{+} http://www.lam-mpi.org/

Re: [Modules] modules 3.1.6 and placement of files

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

On Fri, 27 Jun 2003, Erik Jacobson wrote:

> Hi there.  Thanks for this.
> 
> First of all, after talking with some of my co-workers, I'm considering
> a different approach.  I'm considering installing under /opt, keeping the
> tree just like you would normally expect (see below).

sounds good to me also.

> I'm thinking of changing the RPM spec file to be re-locatable.  If the
> user tries to relocate, I'm thinking to create an /etc/profile.d/modules.csh
> (and sh, etc) to set MODULESHOME.

I had forgotten about /etc/profile.d/ can it be used to set the aliases?
> 
> [root@morale tmp]# ls -l /opt/Modules
> total 0
> drwxr-xr-x    6 root     root           55 Jun 27 10:49 3.1.6
> lrwxrwxrwx    1 root     root            5 Jun 27 10:49 default -> 3.1.6
> drwxr-xr-x    2 root     root            6 Jun 27 07:43 modulefiles
> drwxr-xr-x    2 root     root           18 Jun 27 10:49 versions
> 

However, if you Upgrade or Freshen won't it delete out the 3.1.6 dir and
version anyways?

> 
> This would keep the modules setup more like it is 'out of the box' and give
> people some flexability if they still want to use rpm but locate the
> files elsewhere (ie /usr/local or whatever).
> 
> Does this sound interesting or better?

I'm agreeable to this too.

> Thanks again for the suggestions.
> 
> I'd be happy to send an example spec file if I pull this off.  I think I'm
> nearly done with it.

Sure, so it can be included with the CVS sources.
> 
> On Fri, 27 Jun 2003, R.K. Owen Ph.D. wrote:
> 
> > Hello Erik:
> > I'm the maintainer of the C version.  Your proposal for the modulecmd
> > in /usr/bin and user modules in /usr/share/Modules/ seems in keeping
> > with the intended purposes of those file directories.
> >
> > With the rpm mechanism, you're quite right in that there is no need
> > for the modules versioning system.  I created it to handle
> > modules development, which is less of an issue for rpms.
> >
> > However, I would propose that you keep the modulefiles which are included
> > in the modules distribution separate - /usr/share/Modules/module/modulefiles
> > with /usr/share/Modules/modulefiles for user defined ones.
> >
> > However, a large part of modules is the module alias.  How are you
> > instantiating the aliases in the /etc/ rc files?
> >
> > The current 3.1.6 line Makefile.in doesn't honor the DESTDIR env.var.
> > so I'm curious about your rpm spec file.  Are you just doing an installation
> > in place and then grabbing the rpm source files from the system?
> >
> > I've upgraded the 3.2.x sources to use automake, but the sources have
> > been heavily modified and not yet ready for distribution.  If you want
> > to back-port the 3.2.x Makefile.am and configure.ac to the 3.1.6 line
> > that would be useful, and it would handle most of the DESTDIR issues.
> >
> > I would be happy to include your changes into the 3.1.x line.
> >
> > 	R.K.
> > +------------------+---------------------+
> > | R.K.Owen,PhD     | rk...@ow...    |
> > | KooZ Software    | Environment Modules |
> > | NERSC/LBNL       | rk...@ne...    |
> > +------------------+---------------------+
> >
> > On Thu, 26 Jun 2003, Erik Jacobson wrote:
> >
> > > Hi there.
> > >
> > > I'm making an RPM of the modules package for ia64 redhat.  I have it working
> > > fine in a default sense.
> > >
> > > I've been trying to figure out the best placement of things for
> > > making this pre-packaged in an rpm.  I'm trying to keep both reality and the
> > > filesystem hierarchy standard in mind.
> > >
> > > I'm not sure that using /opt for the modules package is the best option
> > > since it isn't heavily used on a default installation of RedHat.
> > >
> > > /usr/local is supposed to be for local sysadmins (not for packaged
> > > software).  So I'll stay out of there.
> > >
> > > So I decided the best option would be to have the binaries go in to
> > > /usr/bin (modulecmd and such) since they are architecture specific and
> > > have the 3.1.6 module files, versions, and the default location for
> > > user-supplied modules be /usr/share/Modules/.
> > >
> > > The disadvantage of this seems to be that migrating to a new version of
> > > modules isn't done the same way.  This is true for many pre-packaged
> > > things so I'm not sure this is a reason not to do it.
> > >
> > > When playing with configure, I found that passing "--bindir" to configure
> > > properly installed the architecture dependent files in to /usr/bin as I
> > > told it to.  However, the shell init files couldn't find that path -
> > > apparently --bindir isn't used when constructing the init files from
> > > the .in files.
> > >
> > > I guess I have two questions:
> > >
> > >  - If I were to change modules to look at either --bindir or --exec-prefix
> > >    and properly adjust the init files accordingly, is it likely such a
> > >    change would be accepted by the authors assuming it doesn't break anything
> > >    that currently works?
> > >
> > >  - Do you have alternate suggestions on placement of the files?
> > >
> > > I guess if such a change to modules isn't interesting to the authors, I'd
> > > probably go with using /opt and not bother making changes myself to
> > > the modules package.
> > >
> > > --
> > > Erik Jacobson - Linux System Software - Silicon Graphics - Eagan, Minnesota
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by: INetU
> > > Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> > > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> > > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> > > _______________________________________________
> > > Modules-interest mailing list
> > > Mod...@li...
> > > https://lists.sourceforge.net/lists/listinfo/modules-interest
> > >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: INetU
> > Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> > _______________________________________________
> > Modules-interest mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modules-interest
> >
> 
> --
> Erik Jacobson - Linux System Software - Silicon Graphics - Eagan, Minnesota
> 

Re: [Modules] modules 3.1.6 and placement of files

[Erik J. <er...@su...>]

Hi there.  Thanks for this.

First of all, after talking with some of my co-workers, I'm considering
a different approach.  I'm considering installing under /opt, keeping the
tree just like you would normally expect (see below).

I'm thinking of changing the RPM spec file to be re-locatable.  If the
user tries to relocate, I'm thinking to create an /etc/profile.d/modules.csh
(and sh, etc) to set MODULESHOME.

[root@morale tmp]# ls -l /opt/Modules
total 0
drwxr-xr-x    6 root     root           55 Jun 27 10:49 3.1.6
lrwxrwxrwx    1 root     root            5 Jun 27 10:49 default -> 3.1.6
drwxr-xr-x    2 root     root            6 Jun 27 07:43 modulefiles
drwxr-xr-x    2 root     root           18 Jun 27 10:49 versions


This would keep the modules setup more like it is 'out of the box' and give
people some flexability if they still want to use rpm but locate the
files elsewhere (ie /usr/local or whatever).

Does this sound interesting or better?

Thanks again for the suggestions.

I'd be happy to send an example spec file if I pull this off.  I think I'm
nearly done with it.

On Fri, 27 Jun 2003, R.K. Owen Ph.D. wrote:

> Hello Erik:
> I'm the maintainer of the C version.  Your proposal for the modulecmd
> in /usr/bin and user modules in /usr/share/Modules/ seems in keeping
> with the intended purposes of those file directories.
>
> With the rpm mechanism, you're quite right in that there is no need
> for the modules versioning system.  I created it to handle
> modules development, which is less of an issue for rpms.
>
> However, I would propose that you keep the modulefiles which are included
> in the modules distribution separate - /usr/share/Modules/module/modulefiles
> with /usr/share/Modules/modulefiles for user defined ones.
>
> However, a large part of modules is the module alias.  How are you
> instantiating the aliases in the /etc/ rc files?
>
> The current 3.1.6 line Makefile.in doesn't honor the DESTDIR env.var.
> so I'm curious about your rpm spec file.  Are you just doing an installation
> in place and then grabbing the rpm source files from the system?
>
> I've upgraded the 3.2.x sources to use automake, but the sources have
> been heavily modified and not yet ready for distribution.  If you want
> to back-port the 3.2.x Makefile.am and configure.ac to the 3.1.6 line
> that would be useful, and it would handle most of the DESTDIR issues.
>
> I would be happy to include your changes into the 3.1.x line.
>
> 	R.K.
> +------------------+---------------------+
> | R.K.Owen,PhD     | rk...@ow...    |
> | KooZ Software    | Environment Modules |
> | NERSC/LBNL       | rk...@ne...    |
> +------------------+---------------------+
>
> On Thu, 26 Jun 2003, Erik Jacobson wrote:
>
> > Hi there.
> >
> > I'm making an RPM of the modules package for ia64 redhat.  I have it working
> > fine in a default sense.
> >
> > I've been trying to figure out the best placement of things for
> > making this pre-packaged in an rpm.  I'm trying to keep both reality and the
> > filesystem hierarchy standard in mind.
> >
> > I'm not sure that using /opt for the modules package is the best option
> > since it isn't heavily used on a default installation of RedHat.
> >
> > /usr/local is supposed to be for local sysadmins (not for packaged
> > software).  So I'll stay out of there.
> >
> > So I decided the best option would be to have the binaries go in to
> > /usr/bin (modulecmd and such) since they are architecture specific and
> > have the 3.1.6 module files, versions, and the default location for
> > user-supplied modules be /usr/share/Modules/.
> >
> > The disadvantage of this seems to be that migrating to a new version of
> > modules isn't done the same way.  This is true for many pre-packaged
> > things so I'm not sure this is a reason not to do it.
> >
> > When playing with configure, I found that passing "--bindir" to configure
> > properly installed the architecture dependent files in to /usr/bin as I
> > told it to.  However, the shell init files couldn't find that path -
> > apparently --bindir isn't used when constructing the init files from
> > the .in files.
> >
> > I guess I have two questions:
> >
> >  - If I were to change modules to look at either --bindir or --exec-prefix
> >    and properly adjust the init files accordingly, is it likely such a
> >    change would be accepted by the authors assuming it doesn't break anything
> >    that currently works?
> >
> >  - Do you have alternate suggestions on placement of the files?
> >
> > I guess if such a change to modules isn't interesting to the authors, I'd
> > probably go with using /opt and not bother making changes myself to
> > the modules package.
> >
> > --
> > Erik Jacobson - Linux System Software - Silicon Graphics - Eagan, Minnesota
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: INetU
> > Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> > _______________________________________________
> > Modules-interest mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modules-interest
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
>

--
Erik Jacobson - Linux System Software - Silicon Graphics - Eagan, Minnesota

Re: [Modules] modules 3.1.6 and placement of files

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

Hello Erik:
I'm the maintainer of the C version.  Your proposal for the modulecmd
in /usr/bin and user modules in /usr/share/Modules/ seems in keeping
with the intended purposes of those file directories.

With the rpm mechanism, you're quite right in that there is no need
for the modules versioning system.  I created it to handle
modules development, which is less of an issue for rpms.

However, I would propose that you keep the modulefiles which are included
in the modules distribution separate - /usr/share/Modules/module/modulefiles
with /usr/share/Modules/modulefiles for user defined ones.

However, a large part of modules is the module alias.  How are you
instantiating the aliases in the /etc/ rc files?

The current 3.1.6 line Makefile.in doesn't honor the DESTDIR env.var.
so I'm curious about your rpm spec file.  Are you just doing an installation
in place and then grabbing the rpm source files from the system?

I've upgraded the 3.2.x sources to use automake, but the sources have
been heavily modified and not yet ready for distribution.  If you want
to back-port the 3.2.x Makefile.am and configure.ac to the 3.1.6 line
that would be useful, and it would handle most of the DESTDIR issues.

I would be happy to include your changes into the 3.1.x line.

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

On Thu, 26 Jun 2003, Erik Jacobson wrote:

> Hi there.
> 
> I'm making an RPM of the modules package for ia64 redhat.  I have it working
> fine in a default sense.
> 
> I've been trying to figure out the best placement of things for
> making this pre-packaged in an rpm.  I'm trying to keep both reality and the
> filesystem hierarchy standard in mind.
> 
> I'm not sure that using /opt for the modules package is the best option
> since it isn't heavily used on a default installation of RedHat.
> 
> /usr/local is supposed to be for local sysadmins (not for packaged
> software).  So I'll stay out of there.
> 
> So I decided the best option would be to have the binaries go in to
> /usr/bin (modulecmd and such) since they are architecture specific and
> have the 3.1.6 module files, versions, and the default location for
> user-supplied modules be /usr/share/Modules/.
> 
> The disadvantage of this seems to be that migrating to a new version of
> modules isn't done the same way.  This is true for many pre-packaged
> things so I'm not sure this is a reason not to do it.
> 
> When playing with configure, I found that passing "--bindir" to configure
> properly installed the architecture dependent files in to /usr/bin as I
> told it to.  However, the shell init files couldn't find that path -
> apparently --bindir isn't used when constructing the init files from
> the .in files.
> 
> I guess I have two questions:
> 
>  - If I were to change modules to look at either --bindir or --exec-prefix
>    and properly adjust the init files accordingly, is it likely such a
>    change would be accepted by the authors assuming it doesn't break anything
>    that currently works?
> 
>  - Do you have alternate suggestions on placement of the files?
> 
> I guess if such a change to modules isn't interesting to the authors, I'd
> probably go with using /opt and not bother making changes myself to
> the modules package.
> 
> --
> Erik Jacobson - Linux System Software - Silicon Graphics - Eagan, Minnesota
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
> 

[Modules] modules 3.1.6 and placement of files

[Erik J. <er...@su...>]

Hi there.

I'm making an RPM of the modules package for ia64 redhat.  I have it working
fine in a default sense.

I've been trying to figure out the best placement of things for
making this pre-packaged in an rpm.  I'm trying to keep both reality and the
filesystem hierarchy standard in mind.

I'm not sure that using /opt for the modules package is the best option
since it isn't heavily used on a default installation of RedHat.

/usr/local is supposed to be for local sysadmins (not for packaged
software).  So I'll stay out of there.

So I decided the best option would be to have the binaries go in to
/usr/bin (modulecmd and such) since they are architecture specific and
have the 3.1.6 module files, versions, and the default location for
user-supplied modules be /usr/share/Modules/.

The disadvantage of this seems to be that migrating to a new version of
modules isn't done the same way.  This is true for many pre-packaged
things so I'm not sure this is a reason not to do it.

When playing with configure, I found that passing "--bindir" to configure
properly installed the architecture dependent files in to /usr/bin as I
told it to.  However, the shell init files couldn't find that path -
apparently --bindir isn't used when constructing the init files from
the .in files.

I guess I have two questions:

 - If I were to change modules to look at either --bindir or --exec-prefix
   and properly adjust the init files accordingly, is it likely such a
   change would be accepted by the authors assuming it doesn't break anything
   that currently works?

 - Do you have alternate suggestions on placement of the files?

I guess if such a change to modules isn't interesting to the authors, I'd
probably go with using /opt and not bother making changes myself to
the modules package.

--
Erik Jacobson - Linux System Software - Silicon Graphics - Eagan, Minnesota

Re: [Modules] CVS modules and .modules/.modulesrc

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

> Yeah, I am assuming a clean environment. When I started using modules,
> they were very slow and I didn't want to have to wait 10 seconds for every
> shell to start.

I remember - I think I first started playing with modules in the mid/late
80s or so.

> If you want modules to also be forced to load, I *think* you can just set
> the g_force global variable to true. Try that (search for "set g_force 0"
> and change to "set g_force 1"). If this is useful, we can talk where to go
> from there.

Tried that and it mostly worked.  We got some messages about usage counts
being wrong in some _modshare variable, but no details yet.  Form initial
inspection it looks good, though.

H

Re: [Modules] CVS modules and .modules/.modulesrc

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

Yeah, I am assuming a clean environment. When I started using modules, they
were very slow and I didn't want to have to wait 10 seconds for every shell to
start.

If you want modules to also be forced to load, I *think* you can just set the
g_force global variable to true. Try that (search for "set g_force 0" and
change to "set g_force 1"). If this is useful, we can talk where to go from
there.

-Mark

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

On Wed, 25 Jun 2003, Harlan Stenn wrote:

> > hmm. it seems you could just put your 'module' commands in any file of
> > your choice, and then source it from your .cshrc or .profile. It doesn't
> > require any change to the modulecmd.tcl. However, in practice, most users
> > have just one login shell that they will keep until the day they die, and
> > by inheritance, perl scripts and Makefiles will inherit the values from
> > the login shell.
>
> But you are assuming an RC environment that "sets it on login and leaves it
> alone", yes?
>
> I have seen too many places where some process in the chain will alter/clean
> the environment, and this Effects subsequent processes in a bad way.
>
> I had enough trouble with this over the years that I have simply decided
> that each shell invocation must explicitly set the correct environment.
>
> I have also seen problems with jobs started from crontabs (older crons do
> everything from /bin/sh).
>
> Yes, there are hacks to solve lots of these problems, but a more elegant
> solution would be better.
>
> I am trying hard to have a robust "mechanism" that is separate from the
> "policy" of how one uses the mechanism (eg, the policy of "set up modules
> once at login" v. "set up modules at each shell session").
>
> > The 'source' command was for sourcing internal module commands (ie
> > 'prepend-path'), not the external shell commands (ie module load
> > ....). Look at the init/ directory of the tcl release for an
> > example. There probably isn't a wide use for this command. I only put it
> > in there, because the init scripts for each shell were basically doing
> > what 'module' does for free when configuring MODULEPATH. Since MODULEPATH
> > is so inherent to modules, I didn't want to make a module for it, I just
> > wanted to prepend-path.
>
> Thanks - I'll take a look.
>
> H
> --
> > -Mark
> >
> >
> > Mark Lakata, Staff Engineer    1225 Charleston Road       voice 650-567-5170
> > MIPS Technologies              Mountain View CA 94043     fax   650-567-5002
> >
> > On Wed, 25 Jun 2003, Harlan Stenn wrote:
> >
> > > > I didn't even know these existed.  I would tend to not entangle the code
> > with
> > > > these, since they just make things more complicated.  I like to see all t
> > he
> > > > module hooks in one place (the .login/.profile ).
> > >
> > > > that said, there is a hidden feature in the modulecmd.tcl that lets you
> > > > "source" module-like commands without actually loading a module. I use
> > > > this in the initialization scripts for settings the initial MODULEPATH in
> > > > a shell independent manner.
> > >
> > > Details, please!
> > >
> > > The reason I asked about .modules and .modulesrc is that it seems much more
> > > elegant than per-shell-class RC files, which must be maintained in parallel
> > .
> > >
> > > The problem is that if one's module-stuff is in, say, the .cshrc, and one
> > > needs to have the correct environment in any other language (Makefile, shel
> > l
> > > script, perl script, etc) then one has to maintain the module-stuff in all
> > > of those RC files.
> > >
> > > It seems much cleaner to have these "shell"-specific module init things
> > > access a single, shared RC file for all of the modules-stuff.
> > >
> > > H
> > > ---
> > > > On Tue, 24 Jun 2003, Leo Butler wrote:
> > > >
> > > > > Harlan Stenn wrote:
> > > > >
> > > > > > So what is the story with .modules and .modulesrc?
> > > > > >
> > > > > > The code and docs disagree, and I wonder what way
> > > > >  > folks are heading.
> > > > > >
> > > > > > I would like to start adding support for this into
> > > > >  > modulecmd.tcl, but I'm not sure which way to go.
> > > > >
> > > > > Hi Harlan,
> > > > >
> > > > > We don't use it, never have; there's something in the
> > > > > newer mail archives about it.  I can look in the old
> > > > > archives to see if there's anything about these files
> > > > > that might be of use here.
> > > > >
> > > > > Sorry, I'm not of much help on this one.
> > > > >
> > > > > - Leo
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > -------------------------------------------------------
> > > > > This SF.Net email is sponsored by: INetU
> > > > > Attention Web Developers & Consultants: Become An INetU Hosting Partner
> > .
> > > > > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission
> > !
> > > > > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> > > > > _______________________________________________
> > > > > Modules-interest mailing list
> > > > > Mod...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/modules-interest
> > > > >
> > >
>

Re: [Modules] CVS modules and .modules/.modulesrc

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

> hmm. it seems you could just put your 'module' commands in any file of
> your choice, and then source it from your .cshrc or .profile. It doesn't
> require any change to the modulecmd.tcl. However, in practice, most users
> have just one login shell that they will keep until the day they die, and
> by inheritance, perl scripts and Makefiles will inherit the values from
> the login shell.

But you are assuming an RC environment that "sets it on login and leaves it
alone", yes?

I have seen too many places where some process in the chain will alter/clean
the environment, and this Effects subsequent processes in a bad way.

I had enough trouble with this over the years that I have simply decided
that each shell invocation must explicitly set the correct environment.

I have also seen problems with jobs started from crontabs (older crons do
everything from /bin/sh).

Yes, there are hacks to solve lots of these problems, but a more elegant
solution would be better.

I am trying hard to have a robust "mechanism" that is separate from the
"policy" of how one uses the mechanism (eg, the policy of "set up modules
once at login" v. "set up modules at each shell session").

> The 'source' command was for sourcing internal module commands (ie
> 'prepend-path'), not the external shell commands (ie module load
> ....). Look at the init/ directory of the tcl release for an
> example. There probably isn't a wide use for this command. I only put it
> in there, because the init scripts for each shell were basically doing
> what 'module' does for free when configuring MODULEPATH. Since MODULEPATH
> is so inherent to modules, I didn't want to make a module for it, I just
> wanted to prepend-path.

Thanks - I'll take a look.

H
--
> -Mark
> 
> 
> Mark Lakata, Staff Engineer    1225 Charleston Road       voice 650-567-5170
> MIPS Technologies              Mountain View CA 94043     fax   650-567-5002
> 
> On Wed, 25 Jun 2003, Harlan Stenn wrote:
> 
> > > I didn't even know these existed.  I would tend to not entangle the code 
> with
> > > these, since they just make things more complicated.  I like to see all t
> he
> > > module hooks in one place (the .login/.profile ).
> >
> > > that said, there is a hidden feature in the modulecmd.tcl that lets you
> > > "source" module-like commands without actually loading a module. I use
> > > this in the initialization scripts for settings the initial MODULEPATH in
> > > a shell independent manner.
> >
> > Details, please!
> >
> > The reason I asked about .modules and .modulesrc is that it seems much more
> > elegant than per-shell-class RC files, which must be maintained in parallel
> .
> >
> > The problem is that if one's module-stuff is in, say, the .cshrc, and one
> > needs to have the correct environment in any other language (Makefile, shel
> l
> > script, perl script, etc) then one has to maintain the module-stuff in all
> > of those RC files.
> >
> > It seems much cleaner to have these "shell"-specific module init things
> > access a single, shared RC file for all of the modules-stuff.
> >
> > H
> > ---
> > > On Tue, 24 Jun 2003, Leo Butler wrote:
> > >
> > > > Harlan Stenn wrote:
> > > >
> > > > > So what is the story with .modules and .modulesrc?
> > > > >
> > > > > The code and docs disagree, and I wonder what way
> > > >  > folks are heading.
> > > > >
> > > > > I would like to start adding support for this into
> > > >  > modulecmd.tcl, but I'm not sure which way to go.
> > > >
> > > > Hi Harlan,
> > > >
> > > > We don't use it, never have; there's something in the
> > > > newer mail archives about it.  I can look in the old
> > > > archives to see if there's anything about these files
> > > > that might be of use here.
> > > >
> > > > Sorry, I'm not of much help on this one.
> > > >
> > > > - Leo
> > > >
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.Net email is sponsored by: INetU
> > > > Attention Web Developers & Consultants: Become An INetU Hosting Partner
> .
> > > > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission
> !
> > > > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> > > > _______________________________________________
> > > > Modules-interest mailing list
> > > > Mod...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/modules-interest
> > > >
> >

Re: [Modules] CVS modules and .modules/.modulesrc

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

hmm. it seems you could just put your 'module' commands in any file of your
choice, and then source it from your .cshrc or .profile. It doesn't require any
change to the modulecmd.tcl. However, in practice, most users have just one
login shell that they will keep until the day they die, and by inheritance,
perl scripts and Makefiles will inherit the values from the login shell.

The 'source' command was for sourcing internal module commands (ie
'prepend-path'), not the external shell commands (ie module load ....). Look at
the init/ directory of the tcl release for an example. There probably isn't a
wide use for this command. I only put it in there, because the init scripts for
each shell were basically doing what 'module' does for free when configuring
MODULEPATH. Since MODULEPATH is so inherent to modules, I didn't want to make a
module for it, I just wanted to prepend-path.

-Mark


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

On Wed, 25 Jun 2003, Harlan Stenn wrote:

> > I didn't even know these existed.  I would tend to not entangle the code with
> > these, since they just make things more complicated.  I like to see all the
> > module hooks in one place (the .login/.profile ).
>
> > that said, there is a hidden feature in the modulecmd.tcl that lets you
> > "source" module-like commands without actually loading a module. I use
> > this in the initialization scripts for settings the initial MODULEPATH in
> > a shell independent manner.
>
> Details, please!
>
> The reason I asked about .modules and .modulesrc is that it seems much more
> elegant than per-shell-class RC files, which must be maintained in parallel.
>
> The problem is that if one's module-stuff is in, say, the .cshrc, and one
> needs to have the correct environment in any other language (Makefile, shell
> script, perl script, etc) then one has to maintain the module-stuff in all
> of those RC files.
>
> It seems much cleaner to have these "shell"-specific module init things
> access a single, shared RC file for all of the modules-stuff.
>
> H
> ---
> > On Tue, 24 Jun 2003, Leo Butler wrote:
> >
> > > Harlan Stenn wrote:
> > >
> > > > So what is the story with .modules and .modulesrc?
> > > >
> > > > The code and docs disagree, and I wonder what way
> > >  > folks are heading.
> > > >
> > > > I would like to start adding support for this into
> > >  > modulecmd.tcl, but I'm not sure which way to go.
> > >
> > > Hi Harlan,
> > >
> > > We don't use it, never have; there's something in the
> > > newer mail archives about it.  I can look in the old
> > > archives to see if there's anything about these files
> > > that might be of use here.
> > >
> > > Sorry, I'm not of much help on this one.
> > >
> > > - Leo
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by: INetU
> > > Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> > > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> > > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> > > _______________________________________________
> > > Modules-interest mailing list
> > > Mod...@li...
> > > https://lists.sourceforge.net/lists/listinfo/modules-interest
> > >
>

Re: [Modules] modules aliases from /bin/sh (bash)

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

Neat, Mark - thanks!

H

Re: [Modules] CVS modules and .modules/.modulesrc

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

> I didn't even know these existed.  I would tend to not entangle the code with
> these, since they just make things more complicated.  I like to see all the
> module hooks in one place (the .login/.profile ).

> that said, there is a hidden feature in the modulecmd.tcl that lets you
> "source" module-like commands without actually loading a module. I use
> this in the initialization scripts for settings the initial MODULEPATH in
> a shell independent manner.

Details, please!

The reason I asked about .modules and .modulesrc is that it seems much more
elegant than per-shell-class RC files, which must be maintained in parallel.

The problem is that if one's module-stuff is in, say, the .cshrc, and one
needs to have the correct environment in any other language (Makefile, shell
script, perl script, etc) then one has to maintain the module-stuff in all
of those RC files.

It seems much cleaner to have these "shell"-specific module init things
access a single, shared RC file for all of the modules-stuff.

H
---
> On Tue, 24 Jun 2003, Leo Butler wrote:
> 
> > Harlan Stenn wrote:
> >
> > > So what is the story with .modules and .modulesrc?
> > >
> > > The code and docs disagree, and I wonder what way
> >  > folks are heading.
> > >
> > > I would like to start adding support for this into
> >  > modulecmd.tcl, but I'm not sure which way to go.
> >
> > Hi Harlan,
> >
> > We don't use it, never have; there's something in the
> > newer mail archives about it.  I can look in the old
> > archives to see if there's anything about these files
> > that might be of use here.
> >
> > Sorry, I'm not of much help on this one.
> >
> > - Leo
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: INetU
> > Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> > _______________________________________________
> > Modules-interest mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modules-interest
> >

Re: [Modules] modules aliases from /bin/sh (bash)

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

Hon-Chi,

Thanks for your posting.

What you said may be obvious to some, but I hadn't (yet, I hope) thought of
it!

H

Re: [Modules] modules aliases from /bin/sh (bash)

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

The other alternative is to not use aliases.  In the small number of cases
where this has come up, I have created a one line sh script (that execs the
desired command) instead of an alias, and then use the module system to point
PATH to it. (Or I used a symlink in the case where I was just trying to support
a deprecated command name). The $PATH variable is inheritable (even across
different shells), aliases aren't even inheritable across the same shell ...

/bin/sh is so lightweight, that there is no performance hit. And you can "fix"
the script on the fly without having users reload their modules.

-Mark


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

On Tue, 24 Jun 2003, Hon-Chi Ng wrote:

>
> My guess is, short of hacking and re-compiling the source code of bash,
> you have no option but to modify the Makefile or the sh script as you
> previously described, in order to use module under /bin/sh.
>
> However, I modified mine differently, not because it's better solution,
> but the need to use on the version of Solaris before Sun adds /bin/bash
>  :^)
>
> In Makefile, instead of changing SHELL var, I added new var
>   MODULE_LOAD = . $(MODULESHOME)/init/sh && module load
> then in target commands
>         $(MODULE_LOAD) gcc/2.95.3 && gcc ...
>
> In sh script, I just simply added at the top the "good old"
>   . $MODULESHOME/init/sh
>
> Of course, if all hosts have /bin/bash, your approach is more elegant.
>
> Hopefully, I'm not stating the obvious.
>
> Hon-Chi
>
>
> --- Harlan Stenn <Har...@pf...> wrote:
> > So csh/tcsh is nice because it will, be default, read the .cshrc on
> > every
> > instantiation, interactive or not.
> >
> > Current versions of bash will read from the file noted in BASH_ENV on
> > non-interactive startup, which is good.
> >
> > The bad news is that if bash is invoked as a link from /bin/sh it
> > will not
> > process any startup file.
> >
> > How do folks write shell scripts that need access do module shell
> > aliases/functions?  This will also affect usage from inside a
> > Makefile...
> >
> > Is the answer to use SHELL=/bin/bash in a Makefile, and use
> > #!/bin/bash in
> > those scripts that need access to module shell aliases/functions?
> >
> > H
> >
>
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
>

Re: [Modules] CVS modules and .modules/.modulesrc

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

I didn't even know these existed.  I would tend to not entangle the code with
these, since they just make things more complicated.  I like to see all the
module hooks in one place (the .login/.profile ).

that said, there is a hidden feature in the modulecmd.tcl that lets you
"source" module-like commands without actually loading a module. I use this in
the initialization scripts for settings the initial MODULEPATH in a shell
independent manner.


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

On Tue, 24 Jun 2003, Leo Butler wrote:

> Harlan Stenn wrote:
>
> > So what is the story with .modules and .modulesrc?
> >
> > The code and docs disagree, and I wonder what way
>  > folks are heading.
> >
> > I would like to start adding support for this into
>  > modulecmd.tcl, but I'm not sure which way to go.
>
> Hi Harlan,
>
> We don't use it, never have; there's something in the
> newer mail archives about it.  I can look in the old
> archives to see if there's anything about these files
> that might be of use here.
>
> Sorry, I'm not of much help on this one.
>
> - Leo
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
>

Re: [Modules] modules aliases from /bin/sh (bash)

[Hon-Chi Ng <hon...@ya...>]

My guess is, short of hacking and re-compiling the source code of bash,
you have no option but to modify the Makefile or the sh script as you
previously described, in order to use module under /bin/sh.

However, I modified mine differently, not because it's better solution,
but the need to use on the version of Solaris before Sun adds /bin/bash
 :^)

In Makefile, instead of changing SHELL var, I added new var
  MODULE_LOAD = . $(MODULESHOME)/init/sh && module load
then in target commands
        $(MODULE_LOAD) gcc/2.95.3 && gcc ...

In sh script, I just simply added at the top the "good old"
  . $MODULESHOME/init/sh

Of course, if all hosts have /bin/bash, your approach is more elegant.

Hopefully, I'm not stating the obvious.

Hon-Chi


--- Harlan Stenn <Har...@pf...> wrote:
> So csh/tcsh is nice because it will, be default, read the .cshrc on
> every
> instantiation, interactive or not.
> 
> Current versions of bash will read from the file noted in BASH_ENV on
> non-interactive startup, which is good.
> 
> The bad news is that if bash is invoked as a link from /bin/sh it
> will not
> process any startup file.
> 
> How do folks write shell scripts that need access do module shell
> aliases/functions?  This will also affect usage from inside a
> Makefile...
> 
> Is the answer to use SHELL=/bin/bash in a Makefile, and use
> #!/bin/bash in
> those scripts that need access to module shell aliases/functions?
> 
> H
> 


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Re: [Modules] CVS modules and .modules/.modulesrc

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

Harlan Stenn wrote:

> So what is the story with .modules and .modulesrc?
> 
> The code and docs disagree, and I wonder what way
 > folks are heading.
> 
> I would like to start adding support for this into
 > modulecmd.tcl, but I'm not sure which way to go.

Hi Harlan,

We don't use it, never have; there's something in the
newer mail archives about it.  I can look in the old
archives to see if there's anything about these files
that might be of use here.

Sorry, I'm not of much help on this one.

- Leo

[Modules] CVS modules and .modules/.modulesrc

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

So what is the story with .modules and .modulesrc?

The code and docs disagree, and I wonder what way folks are heading.

I would like to start adding support for this into modulecmd.tcl, but I'm
not sure which way to go.

H