modules-interest — Discussion forum for modules usage.

Re: module which ?

[Nils S. <sm...@pd...>]

It sounds like a slow process to parse each module, evaluate the final 
path, and then see if it matches the intended binary. Not to mention that
a module can behave differently depending on what other modules are loaded
(or not loaded) at the time of the load.

I think it is just about as accurate and probably easier to do something
like (in csh syntax):

set target=/usr/local/tuxracer   # I am looking for /usr/local/tuxracer/bin/tuxrace
foreach moddir ( `echo $MODULEPATH | awk -F: '{ for(i=1;i<=NF;i++) {print $i} }'` )
    echo Searching $moddir
    find $moddir -type f -exec grep -q $target \{\} \; -print
end

Searching /usr/local/lib/module/modules
/usr/local/lib/module/modules/tux/1.0

So the relevant module is tux/1.0

It won't work everytime, but you will probably find your module quicker this 
way.

/Nils Smeds

module which ?

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

Hi,

just a couple of comments from developer folks who use modules over
here:

- it is nice that modules obscure PATH, but it is not nice that
  modules obscure binary names that they give access to. Suppose
  a fascist administrator removes /usr/sbin from default PATH,
  how do i know which module gives me access to "fuser" if there
  is no "obvious" module such as "admin" (or make a more complicated
  example of your own). In other words, there's a need for
  "module which <binary name>" that spits out a corresponding
                               module name, or
                <module name>  that spits out a list of binaries/aliases
                               that module gives access to/defines.

- alternatively, there might be "module load ALL" (quite a nice stress
  test for a shell ;-), and afterwards one could unload/switch
  unnecessary modules. It should be able to detect dependencies
  between modules (could be nice for consistency tests).

What do you think ?

Regards,
Gintas

Re: Question about module load

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

Mark,

Thanks for the info.  This seems to work on some occasions, and then not
on others.  Still trying to narrow down the flakiness.

Thanks...

Jon


On Mon, 15 Apr 2002, Mark Moe wrote:

> Jon,
>
> We are doing the same: adding RedHat 7.2 job servers to our LSF queue.
>
> Anyway, this is a hack that I use for LSF and aliases:
>
> 1) we use csh with aliases, so I add this to queue definitions:
>
>   JOB_STARTER = /cadtools/apps/lsf/exec/use_csh
>
> 2) here is my "use_csh" wrapper script:
>
>   #!/cadtools/programs/perl
>   # wrapper to make LSF use csh in a way that aliases are still valid
>
>   # send to /bin/csh
>   open CSH, "| /bin/csh";
>
>   # restore environment vars as they were stored by LSF
>   foreach $key (keys %ENV) {
>     $value = $ENV{$key};
>     $value =~ s/\'/\'\"\'\"\'/g; # in case the value contains single quotes
>     printf CSH "setenv '%s' '%s'\n", $key, $value;
>   }
>
>   # set LM_PROJECT for tracking LSF usage of licensed products
>   print CSH "setenv LM_PROJECT lsf\n";
>
>   # send command
>   $first = shift;
>   print CSH $first;
>   foreach (@ARGV) {
>     print CSH " ";
>     s/\'/\'\"\'\"\'/g; # in case arg contains single quotes
>     print CSH "'$_'"; # single quote args
>   }
>   print CSH "\n";
>   close CSH;
>
> It's messy, but I've been using the above since 1998 and LSF 3.2 (now on LSF 4.2).
>
> - Mark
>
> >>> Jonathan Turenne <jtu...@lu...> 04/15/02 08:31AM >>>
>
> We are introducing linux machines to our solaris environment.  What we are
> doing is setting up a compute farm(LSF) of servers running RedHat 7.2.
> We have 2 issues in doing this:
>
> Issue 1
> -------
> Because all of our tools do not run under linux, our modulefiles contain a
> case statement, which determines the OS, and loads the appropriate
> binaries(if they exist).  Iin the case of tools that do not run under
> linux, I echo a statement to the window, stating that the tool is
> unsupported under linux.  The problem, is that because that case of the
> case statement was resolved, that modulefile shows up when we do a 'module
> list' command.  Is there any sort of "trap" which would allow me to
> control whether the "module list" gets updated if this type of case
> resolves, and there is nothing to set up?  I don't want to load something
> that doesn't exist.
>
>
> Issue 2
> -------
> Is anyone out there running LSF and Modulefiles?  If so, have you noticed
> that the aliases that you set in the modulefiles using the "set-alias"
> command, don't get propagated when submiting a job to LSF?  This happens
> in Solaris & Linux.  Is there any way to get around this?
>
> Any help would be appreciated.
>
> Thanks,
>
> Jon
>
>

Re: Question about module load

[Mark M. <mar...@me...>]

Jon,

We are doing the same: adding RedHat 7.2 job servers to our LSF queue.

Anyway, this is a hack that I use for LSF and aliases:

1) we use csh with aliases, so I add this to queue definitions:

  JOB_STARTER = /cadtools/apps/lsf/exec/use_csh

2) here is my "use_csh" wrapper script:

  #!/cadtools/programs/perl
  # wrapper to make LSF use csh in a way that aliases are still valid
  
  # send to /bin/csh
  open CSH, "| /bin/csh";
  
  # restore environment vars as they were stored by LSF
  foreach $key (keys %ENV) {
    $value = $ENV{$key};
    $value =~ s/\'/\'\"\'\"\'/g; # in case the value contains single quotes
    printf CSH "setenv '%s' '%s'\n", $key, $value;
  }
  
  # set LM_PROJECT for tracking LSF usage of licensed products
  print CSH "setenv LM_PROJECT lsf\n";
  
  # send command
  $first = shift;
  print CSH $first;
  foreach (@ARGV) {
    print CSH " ";
    s/\'/\'\"\'\"\'/g; # in case arg contains single quotes
    print CSH "'$_'"; # single quote args
  }
  print CSH "\n";
  close CSH;

It's messy, but I've been using the above since 1998 and LSF 3.2 (now on LSF 4.2).

- Mark

>>> Jonathan Turenne <jtu...@lu...> 04/15/02 08:31AM >>>

We are introducing linux machines to our solaris environment.  What we are
doing is setting up a compute farm(LSF) of servers running RedHat 7.2.
We have 2 issues in doing this:

Issue 1
-------
Because all of our tools do not run under linux, our modulefiles contain a
case statement, which determines the OS, and loads the appropriate
binaries(if they exist).  Iin the case of tools that do not run under
linux, I echo a statement to the window, stating that the tool is
unsupported under linux.  The problem, is that because that case of the
case statement was resolved, that modulefile shows up when we do a 'module
list' command.  Is there any sort of "trap" which would allow me to
control whether the "module list" gets updated if this type of case
resolves, and there is nothing to set up?  I don't want to load something
that doesn't exist.


Issue 2
-------
Is anyone out there running LSF and Modulefiles?  If so, have you noticed
that the aliases that you set in the modulefiles using the "set-alias"
command, don't get propagated when submiting a job to LSF?  This happens
in Solaris & Linux.  Is there any way to get around this?

Any help would be appreciated.

Thanks,

Jon

Question about module load

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

We are introducing linux machines to our solaris environment.  What we are
doing is setting up a compute farm(LSF) of servers running RedHat 7.2.
We have 2 issues in doing this:

Issue 1
-------
Because all of our tools do not run under linux, our modulefiles contain a
case statement, which determines the OS, and loads the appropriate
binaries(if they exist).  Iin the case of tools that do not run under
linux, I echo a statement to the window, stating that the tool is
unsupported under linux.  The problem, is that because that case of the
case statement was resolved, that modulefile shows up when we do a 'module
list' command.  Is there any sort of "trap" which would allow me to
control whether the "module list" gets updated if this type of case
resolves, and there is nothing to set up?  I don't want to load something
that doesn't exist.


Issue 2
-------
Is anyone out there running LSF and Modulefiles?  If so, have you noticed
that the aliases that you set in the modulefiles using the "set-alias"
command, don't get propagated when submiting a job to LSF?  This happens
in Solaris & Linux.  Is there any way to get around this?

Any help would be appreciated.

Thanks,

Jon

Re: rc problem?

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

On Fri, 12 Apr 2002, Harlan Stenn wrote:

> I've just installed Modules 3.1.6 (speaking of which, any progress or
> thoughts on the patches I sent in to convert Modules to automake or on

I would be *very* interested in having modules built by automake because I
am working to make an RPM for modules.  Since the current build process
does not support $DESTDIR kinds of installs, there is much wailing and
gnashing of teeth on my part while trying to build the RPM on a machine
where modules are already installed.  As result, the %install section in
the specfile is horrible, horrible, horrible...

{+} Jeff Squyres
{+} sq...@cs...
{+} Perpetual Obsessive Notre Dame Student Craving Utter Madness
{+} "I came to ND for 4 years and ended up staying for a decade"

.bashrc problem update

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

I did a little debugging:

hstenn> bash -vx
# start .kshenv
case "$0" in
          -sh|sh|*/sh)  modules_shell=sh ;;
       -ksh|ksh|*/ksh)  modules_shell=ksh ;;
    -bash|bash|*/bash)  modules_shell=bash ;;
esac
+ modules_shell=bash
eval "module() { eval `/usr/local/Modules/\$MODULE_VERSION/bin/modulecmd $modules_shell $*`; }"
/usr/local/Modules/$MODULE_VERSION/bin/modulecmd $modules_shell $*
++ /usr/local/Modules/3.1.6/bin/modulecmd bash
cmdModule.c(169):ERROR:11: Usage is 'bash subcommand  [arguments ...] '

  Modules Release 3.1.6 (Copyright GNU GPL v2 1991):
  Available Commands and Usage:
        + add|load              modulefile [modulefile ...]
        + rm|unload             modulefile [modulefile ...]
        + switch|swap           modulefile1 modulefile2
...

I'm using the "stock" .bashrc that came with the Modules software.

This problem happens to me under bash-2.04 and 2.05a.

H

rc problem?

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

I've just installed Modules 3.1.6 (speaking of which, any progress or
thoughts on the patches I sent in to convert Modules to automake or on my
collate patch or my patch to ignore CVS and SCCS subdirs in the modulefiles
directories?) on a Solaris8 box at a new site.

It seems to be working OK for me for my shell (tcsh), but when I attempt to
build some software I get:

...
config.status: creating config.h
config.status: executing default-1 commands
gmake[1]: Entering directory `/foo/bar/baz'
cmdModule.c(169):ERROR:11: Usage is 'bash subcommand  [arguments ...] '

  Modules Release 3.1.6 (Copyright GNU GPL v2 1991):
  Available Commands and Usage:
        + add|load              modulefile [modulefile ...]
        + rm|unload             modulefile [modulefile ...]
...

Any ideas on how I can debug/identify this problem?

Thanks...

H

poll: installation configuration

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

I'd like to take an informal poll on how people install the modules locally.
There is no real "default", but RKO has proposed to install in

 /usr/local/Modules/$version/bin/modulecmd

I personally use (example)

 /foo/bar/modules-3.1.6/SunOS/bin/modulecmd

since all our machines (SunOS, Linux, HP-UX, IRIX) can mount /foo/bar. The
current init scripts ONLY support the former path, so I wanted to get a feel
for what people use (before I get my hands dirty in the code and init scripts).

My goal is to get rid of the init script, and put everything inside the
modulecmd itself. The way to init the module command would be then:

 eval `/path/to/module/command/modulecmd csh bootstrap`

which would basically do the same as

 source /path/to/module/command/init/csh

but eliminate the need to maintain all those init scripts, and make
installation easier (there is just one file to install).


thanks,
Mark

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

Re: nasty env vars

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

I'm not sure who the vendor is (since I don't know) but the variable name is
PIVOTDB. It is some tool for EDA, although only the support folks use it, not
R&D.

Actually toying around with this, I decided to fix the modules command itself.
I've got it working (finally), but there are some other fixes I would like to
put in before releasing it, especially related to the init scripts and the
configure script.

And in the meantime, I made the module generate a source-able file, instead of
the eval. This of course is not unloadable, but at least it hides the details
from the user for a while.

-Mark

#%Module1.0


set stream none
if [module-info mode load] {
    set stream stdout
}
if [module-info mode display] {
    set stream stderr
}

set cmd(sh)  ". /foo/bar/init.sh"
set cmd(csh) "source /foo/bar/init.csh"

if [info exists cmd([module-info shelltype])] {
    set cmdx      $cmd([module-info shelltype])
    if {$stream != "none"}  {
	puts -nonewline $stream "$cmdx ;"
	flush $stream
    }
}





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

On Wed, 10 Apr 2002, Leo Butler wrote:

> Mark Lakata wrote:
> 
>  > We have one piece of software that requires a nasty env var to be
>  > set. The environment variable contains double-quotes and curly
>  > braces, for example:
>  >
>  > BEGIN{require"/foo/init.pl"}
>  >
>  > (perl hackers will recognize that as perl syntax. Don't ask me who
>  > decided to store a perl one-liner in an env var!)
> 
> Hello, Mark.
> 
> Sorry, I'm gonna do it... WHO IN THE @*)!(*&% did this?  I
> am guessing it's some bit of EDA software code, but I just
> gotta know.
> 
>  > In csh, you can set it with
>  >
>  >  setenv FOO 'BEGIN{require"/foo/init.pl"}'
>  >
>  > However, you will be hardpressed to get this to work in a module!
>  > Try it! The double quotes and the curly braces will ruin your day,
>  > so if you tried that line "as is" in your modulefile, you will get
>  > [snip]
> 
> I'd like to find a modules solution, but 30 minutes of experiments
> has left me as frustrated as you (no, you probably fought with it
> for longer than that...) so I'm going to suggest a punt --
> 
> Make a wrapper script.
> 
> We've been forced into this on some programs due to overruning the
> PATH with all of the EDA tools we wish to load on a per-project
> basis, so it wouldn't be totally without precedent in our env.  I
> hope that's not too outside the norm in yours.
> 
> And in parallel, if the developer is still actively supporting the
> program, ask him/her to fix it.  That's just plain nasty IMHO.
> 
> Regards,
> 
> - Leo
> 
> 

Re: nasty env vars

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

Mark Lakata wrote:

 > We have one piece of software that requires a nasty env var to be
 > set. The environment variable contains double-quotes and curly
 > braces, for example:
 >
 > BEGIN{require"/foo/init.pl"}
 >
 > (perl hackers will recognize that as perl syntax. Don't ask me who
 > decided to store a perl one-liner in an env var!)

Hello, Mark.

Sorry, I'm gonna do it... WHO IN THE @*)!(*&% did this?  I
am guessing it's some bit of EDA software code, but I just
gotta know.

 > In csh, you can set it with
 >
 >  setenv FOO 'BEGIN{require"/foo/init.pl"}'
 >
 > However, you will be hardpressed to get this to work in a module!
 > Try it! The double quotes and the curly braces will ruin your day,
 > so if you tried that line "as is" in your modulefile, you will get
 > [snip]

I'd like to find a modules solution, but 30 minutes of experiments
has left me as frustrated as you (no, you probably fought with it
for longer than that...) so I'm going to suggest a punt --

Make a wrapper script.

We've been forced into this on some programs due to overruning the
PATH with all of the EDA tools we wish to load on a per-project
basis, so it wouldn't be totally without precedent in our env.  I
hope that's not too outside the norm in yours.

And in parallel, if the developer is still actively supporting the
program, ask him/her to fix it.  That's just plain nasty IMHO.

Regards,

- Leo

nasty env vars

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

We have one piece of software that requires a nasty env var to be set. The
environment variable contains double-quotes and curly braces, for example:

BEGIN{require"/foo/init.pl"}

(perl hackers will recognize that as perl syntax. Don't ask me who decided to
store a perl one-liner in an env var!)

In csh, you can set it with

 setenv FOO 'BEGIN{require"/foo/init.pl"}'

However, you will be hardpressed to get this to work in a module! Try it! The
double quotes and the curly braces will ruin your day, so if you tried that
line "as is" in your modulefile, you will get

 BEGINrequire/foo/init.pl

as the env var! This is because of several levels of evals and backticks that
process the line. The curly braces are csh syntax for filename substitution, so
they get erased. The quotes get erased too. The other problem is that you can't
nest quotes like ' or ", and you can't escape " inside a string, only outside a
string (unlike C syntax). You can turn off the {} mangling by using 'set
noglob' in csh, but you have to 'set noglob' on a different line than the one
your are parsing, and eval only accepts one liners! eg

#this works
 eval set noglob
 eval setenv FOO BEGIN{require\"/foo/init.pl\"}

# this doesn't
 eval "set noglob; setenv FOO BEGIN{require\"/foo/init.pl\"}"


ARGH!

I've tried all manner of quoting levels, only to really tear my hair out.  At
some point I got to

 setenv FOO {'"BEGIN{require"\\\"/foo/init.pl\\\""}"'}

which almost worked, but it doesn't. Also, anything that I could kinda make
work would break all the other shell syntaxes.

Any Ideas?


-Mark



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

Insider Secrets of Investing

[<T.C...@co...>]

<html>
<head>
  <title>Secured Investements
  </title>
</head>
<body><font face=3D=22Times, New Roman=22>
<p>
<center>
<table width=3D=22625=22 border=3D0>
  <tbody>
  <tr>
    <td align=3D=22center=22><b><font color=3D=23000033 size=3D6>Earn 15%-300=
% Interest On Your Money</B></font><br>
  <font color=3D=23ff0000 size=3D5><b>GUARANTEED</b> BY THE GOVERNMENT=21
  </font></center></table></tbody></tr></td>
<p>
<table width=3D=22500=22 border=3D0>
  <tbody>
  <tr>
    <td align=3D=22center=22><font color=3D=23000033 size=3D4><b><u>Governmen=
t Secured Tax Cerificates Provide:</u>
    </p></tr></td></font></b>
<p>
<table width=3D=22500=22 border=3D0>
  <tbody>
  <tr>
    <td align=3D=22left=22><font color=3D=23000033 size=3D3>
<li>The highest guaranteed interest returns compared to any other inves=
tment.
<li>A return up to 100 times your money backed by government secured pr=
operty.
<li>Security in your investment that the stock market cannot compare to=
.
</p></table></tbody></tr></td></font></li>
<p>
<table width=3D=22450=22 border=3D0>
  <tbody>
  <tr>
    <td align=3D=22left=22><font color=3D=23000033 size=3D4><b>America's larg=
est single source
  of information/education for the government tax industry.  Celebratin=
g over
  12 years of providing quality, leading edge education for the serious=
 entrepreneur & investor.
</p></table></tbody></tr></td></font></b>
<P>
<CENTER>
<TABLE width=3D=22530=22 border=3D0>
  <TBODY>
  <TR>
    <TD align=3D=22middle=22><FONT color=3D=23000033 size=3D4><B>Receive your=
</font></b><FONT color=3D=23ff0000 size=3D4>
  <b>FREE</b></font><FONT color=3D=23000033 size=3D4><b> copy of </b><FONT=
 color=3D=23ff0000 size=3D4>=22INSIDER SECRETS OF INVESTING
  IN SECURED GOVERNMENT TAX CERTIFICATES.=22</FONT><br> 
  <Font color=3D=23000033><b>(A =2439.95 Value)</FONT></B></TBODY><TR></TA=
BLE>
<br>
<p align=3D=22center=22>
<table width=3D250 border=3D0>
  <tbody>
  <tr>
    <td align=3D=22center=22><font color=3D=23000033><b>Fill out the <i>no o=
bligation</i> form below for more information.
    </table></tbody></tr></td></font></b></P>
<P>
<TABLE width=3D=22400=22 border=3D0>
  <TBODY>
  <TR>
    <TD align=3D=22center=22><FONT color=3D=23000033 size=3D2>Required Input =
Field</font><font color=3D=23ff0000 
    size=3D2>*</FONT></P></TD></TR></TBODY></TABLE>
<P>
<TABLE cellSpacing=3D0 borderColorDark=3D=23333300 cellPadding=3D3 width=3D6=
00 
borderColorLight=3D=23ffffcc>
  <TBODY>
  <TR>
    <TD align=3D=22middle=22>
      <FORM action=3Dmailto:inbocks_dm1=40yahoo.com?subject=3DInvestment_I=
nquiry 
      method=3Dpost encType=3Dtext/plain>
      <TABLE width=3D=22100%=22>
        <TBODY>
        <TR>
          <TD align=3D=22right=22 width=3D=2250%=22><font face=3D=22Times, New =
Roman=22 
            color=3D=23000033 size=3D2>Name</FONT>
            <FONT color=3D=23ff0000 size=3D2>*</FONT></TD>
          <TD><INPUT name=3DNAME></TD></TR>
        <TR>
          <TD align=3D=22right=22 width=3D=2250%=22><font face=3D=22Times, New =
Roman=22 
            color=3D=23000033 size=3D2>State</FONT>
            <FONT color=3D=23ff0000 size=3D2>*</FONT></TD>
          <TD><INPUT size=3D2 name=3DState></TD></TR>
        <TR>
          <TD align=3D=22right=22 width=3D=2250%=22><font face=3D=22Times, New =
Roman=22 
            color=3D=23000033 size=3D2>Day Phone</FONT>
            <FONT color=3D=23ff0000 size=3D2>*</FONT></TD>
          <TD><INPUT name=3DDay Phone></TD></TR>
        <TR>
          <TD align=3D=22right=22 width=3D=2250%=22><font face=3D=22Times, New =
Roman=22 
            color=3D=23000033 size=3D2>Night Phone</FONT></TD>
          <TD><INPUT name=3DNight Phone></TD></TR>
        <TR>
          <TD align=3D=22right=22 width=3D=2250%=22><font face=3D=22Times, New =
Roman=22 
            color=3D=23000033 size=3D2>E-mail Address</FONT>
            <FONT color=3D=23ff0000 size=3D2>*</FONT></TD>
          <TD><INPUT name=3DE-mail Address></TD></TR>
        <TR>
          <TD width=3D=2250%=22>
          <DIV align=3D=22right=22><font face=3D=22Times, New Roman=22 
            color=3D=23000033 size=3D2>Objective</FONT></DIV></TD>
          <TD width=3D=2256%=22><FONT color=3D=23000000><SELECT size=3D1 name=
=3DObjective> 
              <OPTION selected></OPTION> <OPTION 
              value=3DSecured_Investments>Secured Investments</OPTION> <=
OPTION value=3DBusiness_Opp>Business Opp</OPTION> 
              <OPTION value=3DNew_Career>New Career</OPTION><OPTION valu=
e=3DAll_of_the_Above>All of the Above</OPTION>
              </SELECT></FONT></TD></TR></tbody></table>
      <P><INPUT type=3Dsubmit value=3D=22Submit Information=22 name=3Dsubmit=
>
    </FORM></P></TD></TR></TBODY></TABLE>
<br><br>
<p>
<TABLE width=3D450 border=3D0>
  <TBODY>
  <TR>
    <TD align=3Dmiddle><FONT color=3D000000 size=3D2><B>*All investments d=
irectly support local
      fire departments, police departments, schools, roads, and hospita=
ls.  Thank you for your interest and support.</b><br>
      To be removed, please  
      <A href=3D=22mailto:delete7_0=40yahoo.com?subject=3DRemove_Investment=
=22>click 
      here</A></FONT>.</FONT></TD></TR></TBODY></TABLE></P></CENTER>
</BODY></HTML>


*******

RE: modules on cygwin

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

Thanks. I was more interested in the fix than a fixed binary, because I want to
make sure that the source compiles as painlessly as possible. I'm not actually
using CygWin, I was just testing the installation (from the latest CVS source).

I did notice some #ifdef __CYGWIN__'s in the code, but this env var problem has
not gone away.

At somepoint, I tried to just put in a call to the unix
putenv("TCL_LIBRARY=/blah/blah/blah") but it turns out that the modulecmd has
stored a fixed copy of the environment variable table and this modification to
the table causes things to get out of hand and causes segv's and crashes.

(In fact, the current configure script automatically figures out what
TCL_LIBRARY should be and creates a #define in config.h (but it is not used
yet, since I couldn't figure out how to use it). Suggestions welcome, so we
can fix this for the next release.)

-Mark

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

On Tue, 12 Mar 2002, Andy Bruce wrote:

> You need the env var. Also, I ran into problems requiring a special hack to
> the binary for Cygwin. I've attached a zip of the executable if you want it
> (Harlan Stenn sent the source in some time ago; the latest copy on
> sourceforge I think has my fix in it).
> 
> Regards,
> Andy
> 
> 
> 
> 
> -----Original Message-----
> From: Mark Lakata [mailto:la...@mi...]
> Sent: Tuesday, March 12, 2002 1:21 PM
> To: mod...@En...
> Subject: modules on cygwin
> 
> 
> I'm having trouble getting modules to run properly on Cygwin. I get this
> error
> if I try running 'modulecmd.exe sh'
> 
> init.c(425):ERROR:159: Cannot initialize TCL
> 
> 
> I had this problem before on Solaris, and the work arounds were
> 
> (1) Set TCL_LIBRARY or TCLLIBPATH (I can't remember which) to point to
> /usr/local/lib/tcl8.0 so that TCL can find init.tcl
> 
> (2) Recompile TCL so that the paths are correct in the library. (actually,
> it
> was the sysadmin's fault for renaming a path incorrectly)
> 
> 
> However, I can't see anything wrong with the Cygwin TCL installation
> (although
> it is an old 8.0).  From [info library] in the tclsh, i get
> C:/cygwin/usr/share/tcl8.0. If I set
> 
> TCL_LIBRARY=C:/cygwin/usr/share/tcl8.0
> export TCL_LIBRARY
> 
> then it magically works. However, I would like this to work without the env
> var. Any ideas?
> 
> -Mark
> 
> 
> 
> Mark Lakata, Staff Engineer    1225 Charleston Road       voice 650-567-5170
> MIPS Technologies              Mountain View CA 94043     fax   650-567-5002
> 
> 
> 
> 

modules on cygwin

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

I'm having trouble getting modules to run properly on Cygwin. I get this error
if I try running 'modulecmd.exe sh'

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


I had this problem before on Solaris, and the work arounds were

(1) Set TCL_LIBRARY or TCLLIBPATH (I can't remember which) to point to
/usr/local/lib/tcl8.0 so that TCL can find init.tcl

(2) Recompile TCL so that the paths are correct in the library. (actually, it
was the sysadmin's fault for renaming a path incorrectly)


However, I can't see anything wrong with the Cygwin TCL installation (although
it is an old 8.0).  From [info library] in the tclsh, i get
C:/cygwin/usr/share/tcl8.0. If I set

TCL_LIBRARY=C:/cygwin/usr/share/tcl8.0
export TCL_LIBRARY

then it magically works. However, I would like this to work without the env
var. Any ideas?

-Mark



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

Re: Enhancements

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

I wouldn't pass $flag by reference, that seems to be unnecessary complication
(in general, not just for this example). Also, I don't think *defining* a
ModuleAvail function is a good idea, because there could be some complication
in name space conflicts, if two modules declare it.

I would simply create a new command, similar to module-whatis (note: all
lowercase) that is passed a boolean value. I'm a bit concerned that if you
don't understand TCL syntax, you are going to have a large learning curve in
adding new commands ...

What I meant by "$flag is either true or false and determined just prior to
this call" is that first you set flag, and then you call the command. If the
logic is simple, you don't need to use a temporary, just as in my examples.

 set flag [ file isdirectory /tools/gcc/2.95.2 ]
 module-avail $flag

or equivalently

 module-avail [ file isdirectory /tools/gcc/2.95.2 ]

Note: the command 'module-avail' gets executed everytime the module is
referenced (just like module-whatis), but only has an effect if the command is
'module avail ...'.

-Mark

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

On Tue, 5 Mar 2002, Eric Stanley wrote:

> Mark,
> 
> Sorry for the delay in getting back to you; I'm just now getting the
> chance to try to implement this.
> 
> I would like to try to get some clarification on what you're
> suggesting below because I'm not sure what you mean.  Can you help me
> understand what you mean by, "...where $flag is either true or false
> and determined just prior to this call?"
> 
> Perhaps it would work best to explain in more detail what I was
> thinking and you can tell me how (or if) your suggestion differs from
> mine.  I was thinking that there would be a procedure in the
> modulefile something like the following:
> 
> 	proc ModuleAvail { $flag } {
> 		$flag = [ file isdirectory /tools/gcc/2.95.2 ]
> 	}
> 
> You'll have to forgive me if there are syntax errors in the above tcl
> code; my tcl is not very strong and I'm too lazy to look up the
> correct syntax now.  I mean 'flag' to be passed by reference so that
> it's value is returned.
> 
> How then does this differ from what you are saying?
> 
> Thanks for taking the time to comment.
> 
> Eric
> 
> On Thu, Feb 21, 2002 at 10:49:42AM -0800, Mark Lakata wrote:
> > sounds like a good suggestion. I think in keeping with the current calling
> > convention that command would be something like
> > 
> >  module-avail $flag
> > 
> > where $flag is either true or false and determined just prior to this call. If
> > the module-avail is not given in the module, then by default the module is
> > assumed to be available (i.e. to be backwards compatible with all existing
> > modulefiles).
> > 
> > examples:
> > 
> >  module-avail [ file isdirectory /tools/gcc/2.95.2 ]
> > 
> >  module-avail [ string match [ uname sysname ] "Linux" ]
> > 
> > 
> > The rest of the module would be the same.
> > 
> > Mark Lakata, Staff Engineer    1225 Charleston Road       voice 650-567-5170
> > MIPS Technologies              Mountain View CA 94043     fax   650-567-5002
> > 
> > On Thu, 21 Feb 2002, Eric Stanley wrote:
> > 
> > > At our site, we have implemented modulefiles in such a way that there
> > > is only one set of modulefiles across all platforms.  This reduces the
> > > effort required to keep the modulefiles up to date.  In our case the
> > > platforms are a couple versions of Solaris and a couple versions of
> > > Linux.  This does, however, lead to a problem for which I'd like to
> > > suggest a solution and get the list's feedback.
> > > 
> > > The problem arises when doing a 'module avail' command.  Since all
> > > modulefiles are in the modulefiles directory, they are all listed as
> > > being available even though not every version of software is installed
> > > on every platform.  In the modulefile itself the presence or absence
> > > of a particular software package is handled by checking for the
> > > existance of the top level directory of the software package similar
> > > to the following:
> > > 
> > >     if { [ file isdirectory /tools/gcc/2.95.2 ] } {
> > >     	set gcc_home /tools/gcc/2.95.2
> > >         setenv CC gcc
> > >         prepend-path PATH ${gcc_home}/bin
> > >         prepend-path MANPATH ${gcc_home}/man
> > >         prepend-path LD_LIBRARY_PATH ${gcc_home}/lib
> > >     } else {
> > >         break
> > >     }
> > > 
> > > What I would like to suggest that the 'module avail' command check for
> > > the existance of a special procedure with a reserved name in the
> > > modulefile.  The procedure might be named something like 'Avail' and
> > > would return TRUE if the package was really availble on the platform
> > > on which 'module avail' was being run and FALSE otherwise.  If TRUE
> > > was returned, 'module avail' would list the modulefile as being
> > > available, otherwise it would not.  If no such procedure existed,
> > > 'module avail' would use the presence of the modulefile as the only
> > > indication that the modulefile was available.
> > > 
> > > I'd be willing to try to hack in this solution unless we come up with
> > > a better one.  Perhaps there is already a good solution and I just
> > > don't know about it.
> > > 
> > > Thanks for your feedback.
> > > 
> > > Eric
> > > 
> > 
> > 
> > 
> 

Re: Enhancements

[Eric S. <bar...@kn...>]

Mark,

Sorry for the delay in getting back to you; I'm just now getting the
chance to try to implement this.

I would like to try to get some clarification on what you're
suggesting below because I'm not sure what you mean.  Can you help me
understand what you mean by, "...where $flag is either true or false
and determined just prior to this call?"

Perhaps it would work best to explain in more detail what I was
thinking and you can tell me how (or if) your suggestion differs from
mine.  I was thinking that there would be a procedure in the
modulefile something like the following:

	proc ModuleAvail { $flag } {
		$flag = [ file isdirectory /tools/gcc/2.95.2 ]
	}

You'll have to forgive me if there are syntax errors in the above tcl
code; my tcl is not very strong and I'm too lazy to look up the
correct syntax now.  I mean 'flag' to be passed by reference so that
it's value is returned.

How then does this differ from what you are saying?

Thanks for taking the time to comment.

Eric

On Thu, Feb 21, 2002 at 10:49:42AM -0800, Mark Lakata wrote:
> sounds like a good suggestion. I think in keeping with the current calling
> convention that command would be something like
> 
>  module-avail $flag
> 
> where $flag is either true or false and determined just prior to this call. If
> the module-avail is not given in the module, then by default the module is
> assumed to be available (i.e. to be backwards compatible with all existing
> modulefiles).
> 
> examples:
> 
>  module-avail [ file isdirectory /tools/gcc/2.95.2 ]
> 
>  module-avail [ string match [ uname sysname ] "Linux" ]
> 
> 
> The rest of the module would be the same.
> 
> Mark Lakata, Staff Engineer    1225 Charleston Road       voice 650-567-5170
> MIPS Technologies              Mountain View CA 94043     fax   650-567-5002
> 
> On Thu, 21 Feb 2002, Eric Stanley wrote:
> 
> > At our site, we have implemented modulefiles in such a way that there
> > is only one set of modulefiles across all platforms.  This reduces the
> > effort required to keep the modulefiles up to date.  In our case the
> > platforms are a couple versions of Solaris and a couple versions of
> > Linux.  This does, however, lead to a problem for which I'd like to
> > suggest a solution and get the list's feedback.
> > 
> > The problem arises when doing a 'module avail' command.  Since all
> > modulefiles are in the modulefiles directory, they are all listed as
> > being available even though not every version of software is installed
> > on every platform.  In the modulefile itself the presence or absence
> > of a particular software package is handled by checking for the
> > existance of the top level directory of the software package similar
> > to the following:
> > 
> >     if { [ file isdirectory /tools/gcc/2.95.2 ] } {
> >     	set gcc_home /tools/gcc/2.95.2
> >         setenv CC gcc
> >         prepend-path PATH ${gcc_home}/bin
> >         prepend-path MANPATH ${gcc_home}/man
> >         prepend-path LD_LIBRARY_PATH ${gcc_home}/lib
> >     } else {
> >         break
> >     }
> > 
> > What I would like to suggest that the 'module avail' command check for
> > the existance of a special procedure with a reserved name in the
> > modulefile.  The procedure might be named something like 'Avail' and
> > would return TRUE if the package was really availble on the platform
> > on which 'module avail' was being run and FALSE otherwise.  If TRUE
> > was returned, 'module avail' would list the modulefile as being
> > available, otherwise it would not.  If no such procedure existed,
> > 'module avail' would use the presence of the modulefile as the only
> > indication that the modulefile was available.
> > 
> > I'd be willing to try to hack in this solution unless we come up with
> > a better one.  Perhaps there is already a good solution and I just
> > don't know about it.
> > 
> > Thanks for your feedback.
> > 
> > Eric
> > 
> 
> 
> 

3.1.6 bug

[Barbara M. <ba...@cr...>]

I've just installed 3.1.6 on IRIX/SunOS/Cray
network for testing and found this bug:

mymachine => source /opt/modules/3.1.6/init/csh
Unmatched `

Caused by error in line 18 or 20 of ...init/csh

change:
    alias module 'unset histchars;set _prompt="$prompt";eval
`'$exec_prefix'/bin/modulecmd '$modules_shell \!*`;set histchars = $_histchars;
set prompt="$_prompt";unset _prompt'
  else
  alias module 'unset histchars;eval `'$exec_prefix'/bin/modulecmd
'$modules_shell \!*`;set histchars = $_histchars'
  endif

to:
  alias module 'unset histchars;set _prompt="$prompt";eval
`'$exec_prefix'/bin/modulecmd '$modules_shell' \!*`;set histchars = $_histchars;
set prompt="$_prompt";unset _prompt'
  else
  alias module 'unset histchars;eval `'$exec_prefix'/bin/modulecmd
'$modules_shell' \!*`;set histchars = $_histchars'
  endif

Adding the appropriate " ' " makes the error go away.
Most users don't set histchars and so won't see the error when
they take the alternate path.
-- 
Barb Mauzy    |                       Friends help you move. 
Cray Inc.     |           Real friends help you move bodies.
651-605-9027  |

Re: Enhancements

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

sounds like a good suggestion. I think in keeping with the current calling
convention that command would be something like

 module-avail $flag

where $flag is either true or false and determined just prior to this call. If
the module-avail is not given in the module, then by default the module is
assumed to be available (i.e. to be backwards compatible with all existing
modulefiles).

examples:

 module-avail [ file isdirectory /tools/gcc/2.95.2 ]

 module-avail [ string match [ uname sysname ] "Linux" ]


The rest of the module would be the same.

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

On Thu, 21 Feb 2002, Eric Stanley wrote:

> At our site, we have implemented modulefiles in such a way that there
> is only one set of modulefiles across all platforms.  This reduces the
> effort required to keep the modulefiles up to date.  In our case the
> platforms are a couple versions of Solaris and a couple versions of
> Linux.  This does, however, lead to a problem for which I'd like to
> suggest a solution and get the list's feedback.
> 
> The problem arises when doing a 'module avail' command.  Since all
> modulefiles are in the modulefiles directory, they are all listed as
> being available even though not every version of software is installed
> on every platform.  In the modulefile itself the presence or absence
> of a particular software package is handled by checking for the
> existance of the top level directory of the software package similar
> to the following:
> 
>     if { [ file isdirectory /tools/gcc/2.95.2 ] } {
>     	set gcc_home /tools/gcc/2.95.2
>         setenv CC gcc
>         prepend-path PATH ${gcc_home}/bin
>         prepend-path MANPATH ${gcc_home}/man
>         prepend-path LD_LIBRARY_PATH ${gcc_home}/lib
>     } else {
>         break
>     }
> 
> What I would like to suggest that the 'module avail' command check for
> the existance of a special procedure with a reserved name in the
> modulefile.  The procedure might be named something like 'Avail' and
> would return TRUE if the package was really availble on the platform
> on which 'module avail' was being run and FALSE otherwise.  If TRUE
> was returned, 'module avail' would list the modulefile as being
> available, otherwise it would not.  If no such procedure existed,
> 'module avail' would use the presence of the modulefile as the only
> indication that the modulefile was available.
> 
> I'd be willing to try to hack in this solution unless we come up with
> a better one.  Perhaps there is already a good solution and I just
> don't know about it.
> 
> Thanks for your feedback.
> 
> Eric
> 

Re: Enhancements

[Eric S. <bar...@kn...>]

Ed,

I'm not sure what you're asking here.  Are you referring to the
modulefile code snippet below?

If so, that's the way we've chosen to handle a software package not
being installed on the calling platform.  We prefer to have it fail
silently rather than annoy the user with warning messages.  That way
he/she can also have the same modules load command on every platform.

I have implemented a similar check in the ModulesHelp procedure which
will tell the user whether the package is available on the calling
platform when they issue a 'module help <modulename>' command.

With reference to implementing this suggestion, I do have some
development background and would be willing to give it a shot.

Eric

On Thu, Feb 21, 2002 at 01:22:20PM -0500, Edward Arthur wrote:
> That's a great suggestion, but I'm a modules user not developer.
> We have the same situation here (Linux and Solaris) and probably
> the same set of tools..
> 
> Would you want to "break" or have an error message?
> 
> /Ed
> 
> Eric Stanley wrote:
> > 
> > At our site, we have implemented modulefiles in such a way that there
> > is only one set of modulefiles across all platforms.  This reduces the
> > effort required to keep the modulefiles up to date.  In our case the
> > platforms are a couple versions of Solaris and a couple versions of
> > Linux.  This does, however, lead to a problem for which I'd like to
> > suggest a solution and get the list's feedback.
> > 
> > The problem arises when doing a 'module avail' command.  Since all
> > modulefiles are in the modulefiles directory, they are all listed as
> > being available even though not every version of software is installed
> > on every platform.  In the modulefile itself the presence or absence
> > of a particular software package is handled by checking for the
> > existance of the top level directory of the software package similar
> > to the following:
> > 
> >     if { [ file isdirectory /tools/gcc/2.95.2 ] } {
> >         set gcc_home /tools/gcc/2.95.2
> >         setenv CC gcc
> >         prepend-path PATH ${gcc_home}/bin
> >         prepend-path MANPATH ${gcc_home}/man
> >         prepend-path LD_LIBRARY_PATH ${gcc_home}/lib
> >     } else {
> >         break
> >     }
> > 
> > What I would like to suggest that the 'module avail' command check for
> > the existance of a special procedure with a reserved name in the
> > modulefile.  The procedure might be named something like 'Avail' and
> > would return TRUE if the package was really availble on the platform
> > on which 'module avail' was being run and FALSE otherwise.  If TRUE
> > was returned, 'module avail' would list the modulefile as being
> > available, otherwise it would not.  If no such procedure existed,
> > 'module avail' would use the presence of the modulefile as the only
> > indication that the modulefile was available.
> > 
> > I'd be willing to try to hack in this solution unless we come up with
> > a better one.  Perhaps there is already a good solution and I just
> > don't know about it.
> > 
> > Thanks for your feedback.
> > 
> > Eric
> 

Re: Enhancements

[Edward A. <ed...@ul...>]

That's a great suggestion, but I'm a modules user not developer.
We have the same situation here (Linux and Solaris) and probably
the same set of tools..

Would you want to "break" or have an error message?

/Ed

Eric Stanley wrote:
> 
> At our site, we have implemented modulefiles in such a way that there
> is only one set of modulefiles across all platforms.  This reduces the
> effort required to keep the modulefiles up to date.  In our case the
> platforms are a couple versions of Solaris and a couple versions of
> Linux.  This does, however, lead to a problem for which I'd like to
> suggest a solution and get the list's feedback.
> 
> The problem arises when doing a 'module avail' command.  Since all
> modulefiles are in the modulefiles directory, they are all listed as
> being available even though not every version of software is installed
> on every platform.  In the modulefile itself the presence or absence
> of a particular software package is handled by checking for the
> existance of the top level directory of the software package similar
> to the following:
> 
>     if { [ file isdirectory /tools/gcc/2.95.2 ] } {
>         set gcc_home /tools/gcc/2.95.2
>         setenv CC gcc
>         prepend-path PATH ${gcc_home}/bin
>         prepend-path MANPATH ${gcc_home}/man
>         prepend-path LD_LIBRARY_PATH ${gcc_home}/lib
>     } else {
>         break
>     }
> 
> What I would like to suggest that the 'module avail' command check for
> the existance of a special procedure with a reserved name in the
> modulefile.  The procedure might be named something like 'Avail' and
> would return TRUE if the package was really availble on the platform
> on which 'module avail' was being run and FALSE otherwise.  If TRUE
> was returned, 'module avail' would list the modulefile as being
> available, otherwise it would not.  If no such procedure existed,
> 'module avail' would use the presence of the modulefile as the only
> indication that the modulefile was available.
> 
> I'd be willing to try to hack in this solution unless we come up with
> a better one.  Perhaps there is already a good solution and I just
> don't know about it.
> 
> Thanks for your feedback.
> 
> Eric

Enhancements

[Eric S. <bar...@kn...>]

At our site, we have implemented modulefiles in such a way that there
is only one set of modulefiles across all platforms.  This reduces the
effort required to keep the modulefiles up to date.  In our case the
platforms are a couple versions of Solaris and a couple versions of
Linux.  This does, however, lead to a problem for which I'd like to
suggest a solution and get the list's feedback.

The problem arises when doing a 'module avail' command.  Since all
modulefiles are in the modulefiles directory, they are all listed as
being available even though not every version of software is installed
on every platform.  In the modulefile itself the presence or absence
of a particular software package is handled by checking for the
existance of the top level directory of the software package similar
to the following:

    if { [ file isdirectory /tools/gcc/2.95.2 ] } {
    	set gcc_home /tools/gcc/2.95.2
        setenv CC gcc
        prepend-path PATH ${gcc_home}/bin
        prepend-path MANPATH ${gcc_home}/man
        prepend-path LD_LIBRARY_PATH ${gcc_home}/lib
    } else {
        break
    }

What I would like to suggest that the 'module avail' command check for
the existance of a special procedure with a reserved name in the
modulefile.  The procedure might be named something like 'Avail' and
would return TRUE if the package was really availble on the platform
on which 'module avail' was being run and FALSE otherwise.  If TRUE
was returned, 'module avail' would list the modulefile as being
available, otherwise it would not.  If no such procedure existed,
'module avail' would use the presence of the modulefile as the only
indication that the modulefile was available.

I'd be willing to try to hack in this solution unless we come up with
a better one.  Perhaps there is already a good solution and I just
don't know about it.

Thanks for your feedback.

Eric

Re: modules with rsh/ssh

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

On Mon, 18 Feb 2002, Jerry Hershkowitz wrote:

> As a mere mortal, I can give you a suggestion.  But, I'd like to hear
> what some of the more knowlegable Modules creators might have to say,
> too, about why the default modules installation has the C-shell
> installation split between the .login and .cshrc files.

My understanding of this is that this is an optimization.

There is some one-time initialization that can be done that will persist
across sub-shells (e.g., environment variables).  This stuff can be done
in .login so that it executes only once (although its effects last for all
children of the login shell).  Other things (such as aliases) are only
per-shell and are not inherited by children.  Hence, they must be setup
for every shell invocation.

{+} Jeff Squyres
{+} sq...@cs...
{+} Perpetual Obsessive Notre Dame Student Craving Utter Madness
{+} "I came to ND for 4 years and ended up staying for a decade"

x-resource not working?

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

I have been using modules-2.2beta for a long time and it's work rather well.
We've finally got some RH7.2 machines that won't run the old code because for
some reason, TCL8.3 is not backwards compatible with TCL8.0 !

I've tried 3.x a few times, only to hit segv's on 'module unload ...'. So I
thought I would try 3.1.6 one more time, and while I am not getting the segvs,
the x-resource command is not doing anything.

In my module file, I have:

 x-resource {Iexplorer*background: #c0c0c0}

while when I query the xrdb, I get:

% xrdb -query
! screen-independent resources
:       #c0c0c0

which you can see has lost the "Iexplorer*background" bit. I've gone through
the code with the gdb debugger, and it seems that this is a problem in the
modulecmd program, because I see the line where it calls XChangeProperty() and
it is missing the "Iexplorer*background" bit also. Is there some trick to get
this to work? It used to work great in 2.2.  Except for the installation path,
I'm using all the defaults for ./configure.

(and someone else has gone through the code and misspelled the word "ressource"
[sic] in the comments ... it was fine in 2.2)

There are some other problems with x-resource hanging or crashing ungracefully
if $DISPLAY and/or xhost is not set correctly, but I'll worry about that
later...

 -Mark


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

Re: modules with rsh/ssh

[Lloyd C. C. <lc...@po...>]

Once upon a time (like on Feb 18, 2002), Jerry Hershkowitz wrote:
> (First, I too am greatful for the Gods who created Modules.)

Agreed :)

> So, in my .cshrc, I have:
> 
> ############################################################
> source <modules_installation_path>/modules/etc/csh.modules
> if ($LOADEDMODULES  == "null") then
>   echo "csh.modules already sourced;  only null module loaded"
>   # put here modules you always want loaded
>   module load openwin
>   module load gnutools
>   module load man
> #else
> #  module update
> endif
> ############################################################

I have just a brief comment here.  It's more efficient to specify the
modules in one load command like this:

   module load openwin gnutools man

especially if they require additions to the PATH.  Whenever an element
is added to a user's path, a rehash is needed which can take a
significant amount of time if the paths are long.

-L