modules-interest — Discussion forum for modules usage.

Re: support for rc or es shells?

[Assar W. <as...@si...>]

Axel Belinfante <Axe...@cs...> writes:
> We are still using modules 2.2b (with some patches,
> which I posted to this list already some time ago) in our group,
> and I haven't followed the developments closely,
> but maybe someone knows the answer to this question:
> 
>    has support been added for the rc shell (from plan9) or the es shell?

I dunno about that since I haven't followed it enough either to figure
which is the `latest' or `current' version, but I hacked in es support
in 2.2b a long time ago and include the patches here, FWIW.  I think
they should also work with rc.  Hope it's helpful.

/assar

--- init-1.1.c	Tue Feb 29 20:35:06 2000
+++ init.c	Tue Feb 29 20:34:54 2000
@@ -276,6 +276,10 @@
 	shell_startups[1] = ".zshenv";
 	shell_startups[2] = ".zlogin";
 	shell_startups[3] = NULL;
+    } else if((strcmp("es", shell_name) == 0)) { 
+	shell_startups = (char**) malloc(2*sizeof(char*));
+	shell_startups[0] = ".esrc";
+	shell_startups[3] = NULL;
     } else {
 	shell_startups = (char**) malloc(1*sizeof(char*));
 	shell_startups[0] = NULL;
--- utility.c	1994/12/03 00:03:34	1.1
+++ utility.c	1994/12/04 02:41:56	1.2
@@ -619,6 +619,8 @@
       fprintf(stdout, "(setenv \"%s\" \"%s\")\n", var, val);
   } else if(!strcmp((char*) shell_derelict, "perl")) {
       fprintf(stdout, "$ENV{'%s'} = \"%s\"%c", var, val, cmd_separator);  
+  } else if(!strcmp((char*) shell_derelict, "es")) {
+      fprintf(stdout, "%s=%s%c", var, val, cmd_separator);
   } else {
     fprintf(stderr, 
 	    "ERROR in output_set_shell_variable():  Unrecognized shell derelict %s\n", 
@@ -639,6 +641,8 @@
       fprintf(stdout, "(setenv \"%s\" nil)\n", var);
   } else if(!strcmp((char*) shell_derelict, "perl")) {
       fprintf(stdout, "delete $ENV{'%s'}%c", var, cmd_separator);  
+  } else if(!strcmp((char*) shell_derelict, "es")) {
+      fprintf(stdout, "%s=%c", var, cmd_separator);
   } else {
     fprintf(stderr, 
 	    "ERROR in output_unset_shell_variable():  Unrecognized shell derelict %s\n", 
@@ -663,6 +667,8 @@
 	return strcpy(shell_derelict, "emacs");
     } else if(!strcmp((char*) name, "perl")) {
 	return strcpy(shell_derelict, "perl");
+    } else if(!strcmp((char*) name, "es")) {
+	return strcpy(shell_derelict, "es");
     }
 
     return NULL;
@@ -767,6 +773,8 @@
              */
             fprintf(aliasfile, "alias %s='%s'%c", var, val, alias_separator);
         }
+    } else if(!strcmp(shell_derelict, "es")) {
+        fprintf(aliasfile, "fn %s { %s }%c", var, val, alias_separator);
     }
     return TCL_OK;
 }
@@ -819,8 +827,9 @@
             fprintf(aliasfile, "unalias %s%c", var, alias_separator);
             fprintf(aliasfile, "unset -f %s%c", var, alias_separator);
         }
+    } else if(!strcmp(shell_derelict, "es")) {
+        fprintf(aliasfile, "fn %s;", var, alias_separator);
     }
-    
     return TCL_OK;
 }
 
--- /dev/null	Tue Feb 29 20:04:35 2000
+++ init/es.in	Sat Dec  3 00:42:55 1994
@@ -0,0 +1,11 @@
+exec_prefix=@prefix@
+
+fn module args {
+  eval `{$exec_prefix/bin/modulecmd es $args}
+}
+
+MODULESHOME=@prefix@
+
+if {~ $MODULEPATH ()} {
+  MODULEPATH=@prefix@/modulefiles
+}

support for rc or es shells?

[Axel B. <Axe...@cs...>]

We are still using modules 2.2b (with some patches,
which I posted to this list already some time ago) in our group,
and I haven't followed the developments closely,
but maybe someone knows the answer to this question:

   has support been added for the rc shell (from plan9) or the es shell?

Axel.
-- 
 <Axe...@cs...>   <URL:http://www.cs.utwente.nl/~belinfan/>
 University of Twente, Dept. of Computer Science, Formal Methods & Tools Group
 P.O. Box 217; NL-7500 AE Enschede.  Phone: +31 53 4893774; Fax: +31 53 4893247
     "ili ne sciis ke estas neebla do ili simple faris" -- Loesje

Re: Modules Paper?

[Timothy D. <dem...@ar...>]

>>>>> "Richard" == Richard Abato <rp...@in...>
>>>>> wrote the following on Mon, 28 Feb 2000 12:48:35 -0500 (EST)

  Richard> The Modules README says that a copy of the paper "Modules:
  Richard> Providing a Flexible User Environment" is included in the doc
  Richard> directory in postscript form.  I did find a file
  Richard> "Modules-Paper.doc" but it doesn't appear to be postscript and
  Richard> is also doesn't appear to be an MS Word document either.  Does
  Richard> anyone know what format this is?  Is a postscript, pdf or MS
  Richard> Word version available anywhere?

The abstract is available from USENIX (www.usenix.org):

Author: John L. Furlani
       Title: Modules: Providing a Flexible User Environment
       Pages: 141-152
   Publisher: USENIX
 Proceedings: LISA V Conference Proceedings
        Date: September 30 - October 3, 1991
    Location: San Diego, CA
 Institution: Sun Microsystems Inc.


This paper is actually available online at USENIX:

      Author: John L. Furlani
      Author: Peter W. Osel
       Title: Abstract Yourself With Modules
       Pages: 193-203
   Publisher: USENIX
 Proceedings: 10th Systems Administration Conference (LISA'96)
        Date: September 29 - October 4, 1996
    Location: Chicago, IL
 Institution: Sun Microsystems, Inc. (author #1)
 Institution: Siemens Components, Inc. (author #2)

Hope this helps.

Tim


--
Timothy Demarest                      ArrayComm, Inc.  
dem...@ar...                3141 Zanker Road  
http://www.arraycomm.com              San Jose, CA 95134

Re: Modules Paper?

[Roberto B. <Rob...@ge...>]

On Mon, 28 Feb 2000, Richard Abato wrote:

> 
> I did find a file "Modules-Paper.doc" but it doesn't appear to be
> postscript and is also doesn't appear to be an MS Word document either.  
> Does anyone know what format this is?  Is a postscript, pdf or MS Word 
> version available anywhere?
> 

This is FrameMaker (an old version also)!
Unfortunately i do not have the ps or pdf but if i remember correctly it is a
litle bit too old.

Ciao
	Roberto

-- 
E-Mail:	Rob...@ge...	Mail-Address:	INFN - Sez. di Genova
Phone:	+39 10 353-6301					Via Dodecaneso, 33
Fax:	+39 10 353-6319					I-16146 GENOVA

Modules Paper?

[Richard A. <rp...@in...>]

The Modules README says that a copy of the paper "Modules: Providing a
Flexible User Environment" is included in the doc directory in postscript 
form.  I did find a file "Modules-Paper.doc" but it doesn't appear to be
postscript and is also doesn't appear to be an MS Word document either.  
Does anyone know what format this is?  Is a postscript, pdf or MS Word 
version available anywhere?

Thanks

Rich



-----------------------------     ------------------------------------
Richard Abato                \   /  Intrinsix, Corp.                  
Principal Consulting Engineer \ /   71 Spit Brook Road
email: rp...@in...       X    Suite 409                        
voice: (603) 891-1044 X101    / \   Nashua, NH 03060                
fax:   (603) 891-1021        /   \  http://www.intrinsix.com
-----------------------------     -----------------------------------
The #1 independent ASIC design services company in the U.S.

modules 2.2beta, hacked to work with tcl8

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

I just stumbled on this list. I used Modules for a long time at LBL, but
now I want to use it at my new job.

Version 2.2beta doesn't work properly with Tcl8*. The problem is that the
Makefile doesn't have warnings turned on, so somehow it manages to compile
even though a particular routine isn't defined in Tcl8 (GlobCmd). I have
patched 2.2beta so that it will compile with Tcl8 (at least version
8.0p2).

I'm not sure that anyone cares about 2.2 anymore, but it seems that not
everyone is ready for version 3 yet. (I haven't tried it yet!)

Is there a home page for Modules? ftp.modules.org doesn't seem to exist
anymore, if it ever did!

-Mark Lakata

to patch, first untar the original 2.2beta distribution. Copy this email
to init.patch, and then run

patch < init.patch

from the Modules-v2.2BETA directory. Then remake.


 CUT HERE, REMOVE ALL TEXT ABOVE THIS LINE INCLUDING THIS LINE
*** Modules-v2.2BETA/init.c	Thu Jun 30 16:17:19 1994
--- Modules-v2.2BETA-mine/init.c	Fri Feb 25 18:15:56 2000
***************
*** 147,166 ****
      if(getenv("_MODULESBEGINENV_") == NULL) {
          char*  argv[3];
          FILE*  file;
!         
          argv[1] = "~/.modulesbeginenv";
          argv[2] = NULL;
  
          if(Tcl_GlobCmd(0, *interp, 2, argv) == TCL_OK) {
!             if((file = fopen((*interp)->result, "w+")) != NULL) {
!                 int i=0;
!                 while(environ[i]) {
!                     fprintf(file, "%s\n", environ[i++]);
!                 }
!                 moduleSetenv(*interp, "_MODULESBEGINENV_", (*interp)->result, 1);
!                 fclose(file);
!             }
!         }
      }
  
      return 0;
--- 147,176 ----
      if(getenv("_MODULESBEGINENV_") == NULL) {
          char*  argv[3];
          FILE*  file;
! #if TCL_MAJOR_VERSION == 8
! 	Tcl_DString path;
! #endif
! 
          argv[1] = "~/.modulesbeginenv";
          argv[2] = NULL;
  
+ #if TCL_MAJOR_VERSION == 8
+         if(Tcl_TranslateFileName(*interp, argv[1],&path)) {
+ #else
          if(Tcl_GlobCmd(0, *interp, 2, argv) == TCL_OK) {
! #endif
! 	  if((file = fopen((*interp)->result, "w+")) != NULL) {
! 	    int i=0;
! 	    while(environ[i]) {
! 	      fprintf(file, "%s\n", environ[i++]);
! 	    }
! 	    moduleSetenv(*interp, "_MODULESBEGINENV_", (*interp)->result, 1);
! 	    fclose(file);
! 	  }
! 	}
! #if TCL_MAJOR_VERSION == 8
! 	Tcl_DStringFree(&path);
! #endif
      }
  
      return 0;

3.0.6-rko blank avail fix

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

As a couple of people have noticed on Sun systems the "module avail"
produced no output.  I've discovered the problem, and I'm surprised
that the code worked just fine on Linux & AIX, which is probably an
artifact of how the stack is laid out.
Anyways, just make the following change as directed by this
uniform context sensitive patch to utility.c.
A new version of modules will be uploaded next week sometime
with some other changes.
Thanks for all those that raised the alert.
	R.K.

+-----------------------+----------------------------------+
| R.K.Owen,PhD          | rk...@ow...                 |
| KooZ Software         |                                  |
| NERSC/LBNL            | rk...@ne...   (510)486-7556 |
+-----------------------+----------------------------------+
Index: utility.c
===================================================================
RCS file: /usr/src/cvsroot/modules-3.0rko/utility.c,v
retrieving revision 1.8
diff -u -r1.8 utility.c
--- utility.c   2000/01/22 02:54:51     1.8
+++ utility.c   2000/02/24 16:00:04
@@ -2657,6 +2657,6 @@

        if (var == (char *)NULL) return result;

-       xdup(getenv(var));
+       return xdup(getenv(var));

 } /** End of 'xgetenv' **/

Re: Modules update to 3.0.6-rko and avail

[Richard A. <rp...@in...>]

Hi All,
  I have the same problem with 3.0.6 built on Sun/Solaris with 
tcl 8.2.2 and gcc 2.95.2.   "module avail" shows nothing.

  I would also like to thank R. K. Owen for his hard work!  

Rich

On Thu, 17 Feb 2000, Andrew Watkins wrote:

> 
> Just downloaded the new release and had a quick play, but
> I notice that "module avail" shows nothing....
> 
> I have tried 
> % module avail
> % module avail /bbkdcs/Modules3/default/modulefiles
> 
> but I get not output back. Funny thing is that "module add"
> and "module list" work fine.
> 
> Has anyone else getting this.
> I have tried tcl8.3 and tcl8.0, but with out any luck.
> Also, modules-3.0.4-rko was working fine except for the switch problems
> as mention before.
> 
> 
> And finally a BIG thanks to R.K.Owen for all the work done on modules.
> 
> 
> Andrew Watkins
> 
> 

-----------------------------     ------------------------------------
Richard Abato                \   /  Intrinsix, Corp.                  
Principal Consulting Engineer \ /   71 Spit Brook Road
email: rp...@in...       X    Suite 409                        
voice: (603) 891-1044 X101    / \   Nashua, NH 03060                
fax:   (603) 891-1021        /   \  http://www.intrinsix.com
-----------------------------     -----------------------------------
The #1 independent ASIC design services company in the U.S.

Re: space-separated paths

[Simon B. <ba...@ga...>]

Thanks, but this is a variation on what we have at present.
The problem is that when you 
	puts -nonewline "setenv $var '$envtmp';"
for example, this causes setenv to be executed by the shell.
Unfortunately, sh and ksh don't have a setenv command so an
error is generated.  I imagine the same would go for Perl
and any other non-C-shell-like environments.

It's possible to emulate the setenv command, more or less, with a
ksh function, but it's not as easy as it sounds to pass spaces
through layers of shells and evals.  I tried one version published
in a Korn shell book which did _not_ work.

Simon
-----
>Try this in your modulefile. I use this to modify environment
>variables for compiler options.
>If the module command does not have it, you can use tcl to
>extend it capabilities.
>
>regards,
>Don
>-------------------------------------- cut 
-----------------------------
># author: dpm
># usage: prepend-env VAR arg
>#        append-env  VAR arg
># arg must be double quoted if it contains whitespace
>#
>proc ldelete { l v } {
>  set ix [lsearch -exact $l $v]
>  if {$ix >= 0} {
>    return [lreplace $l $ix $ix]
>  } else {
>    return $l
>  }
>}
>
>proc remove-env  {var {rem_val ""} } {
>    global env envtmp
>    foreach i $rem_val {
>       set envtmp  [ldelete $envtmp $i]
>    }
>    if {[string compare $envtmp ""] == 0} {
>       puts -nonewline "unsetenv $var ;"
>    } else {
>       puts -nonewline "setenv $var '$envtmp';"
>    }
>}
>
>proc prepend-env {var {new_val ""} } {
>    global env envtmp
>    if { ! [info exists env($var)]} {
>        set envtmp ""
>    } else {
>        set envtmp $env($var)
>    }
>    if {[module-info mode load]} {
>       foreach i $new_val {
>           set ix [lsearch -exact $envtmp $i]
>           if {$ix < 0} {
>               set envtmp "$i $envtmp"
>           }
>       }
>    }
>    puts stderr "envtmp is $envtmp"
>    case [module-info mode] in {
>        "load" {puts -nonewline "setenv $var '$envtmp';"}
>        "remove" {remove-env $var $new_val}
>    }
>}
>
>proc append-env {var {new_val ""} } {
>    global env envtmp
>    if { ! [info exists envtmp]} {
>        set envtmp $env($var)
>    }
>    if {[module-info mode load]} {
>       foreach i $new_val {
>           set ix [lsearch -exact $envtmp $i]
>           if {$ix < 0} {
>               puts stderr "$i does not exist in $var"
>               set envtmp "$i $envtmp"
>           }
>       }
>    }
>    case [module-info mode] in {
>        "load" {puts -nonewline "setenv $var '$envtmp';"}
>        "remove" {remove-env $var $new_val}
>    }
>}

Re: space-separated paths

[Don M. <dp...@sg...>]

Simon Barnes wrote:
> 
> Are there any good techniques for dealing with space-separated
> paths in modules?  $INC_PATH is an example.  We have a
> shell-specific solution but dealing with multiple shells
> is harder and would seem to call for some new functionality
> in modules itself.  You can't just use setenv because this causes
> $INC_PATH to be wiped out when the module is unloaded.
> 
> TIA
> Simon
Simon,
Try this in your modulefile. I use this to modify environment
variables for compiler options.
If the module command does not have it, you can use tcl to
extend it capabilities.

regards,
Don
-------------------------------------- cut -----------------------------
# author: dpm
# usage: prepend-env VAR arg
#        append-env  VAR arg
# arg must be double quoted if it contains whitespace
#
proc ldelete { l v } {
  set ix [lsearch -exact $l $v]
  if {$ix >= 0} {
    return [lreplace $l $ix $ix]
  } else {
    return $l
  }
}

proc remove-env  {var {rem_val ""} } {
    global env envtmp
    foreach i $rem_val {
       set envtmp  [ldelete $envtmp $i]
    }
    if {[string compare $envtmp ""] == 0} {
       puts -nonewline "unsetenv $var ;"
    } else {
       puts -nonewline "setenv $var '$envtmp';"
    }
}

proc prepend-env {var {new_val ""} } {
    global env envtmp
    if { ! [info exists env($var)]} {
        set envtmp ""
    } else {
        set envtmp $env($var)
    }
    if {[module-info mode load]} {
       foreach i $new_val {
           set ix [lsearch -exact $envtmp $i]
           if {$ix < 0} {
               set envtmp "$i $envtmp"
           }
       }
    }
    puts stderr "envtmp is $envtmp"
    case [module-info mode] in {
        "load" {puts -nonewline "setenv $var '$envtmp';"}
        "remove" {remove-env $var $new_val}
    }
}

proc append-env {var {new_val ""} } {
    global env envtmp
    if { ! [info exists envtmp]} {
        set envtmp $env($var)
    }
    if {[module-info mode load]} {
       foreach i $new_val {
           set ix [lsearch -exact $envtmp $i]
           if {$ix < 0} {
               puts stderr "$i does not exist in $var"
               set envtmp "$i $envtmp"
           }
       }
    }
    case [module-info mode] in {
        "load" {puts -nonewline "setenv $var '$envtmp';"}
        "remove" {remove-env $var $new_val}
    }
}

space-separated paths

[Simon B. <ba...@ga...>]

Are there any good techniques for dealing with space-separated
paths in modules?  $INC_PATH is an example.  We have a
shell-specific solution but dealing with multiple shells
is harder and would seem to call for some new functionality
in modules itself.  You can't just use setenv because this causes
$INC_PATH to be wiped out when the module is unloaded.

TIA
Simon

Modules update to 3.0.6-rko and avail

[Andrew W. <an...@dc...>]

Just downloaded the new release and had a quick play, but
I notice that "module avail" shows nothing....

I have tried 
% module avail
% module avail /bbkdcs/Modules3/default/modulefiles

but I get not output back. Funny thing is that "module add"
and "module list" work fine.

Has anyone else getting this.
I have tried tcl8.3 and tcl8.0, but with out any luck.
Also, modules-3.0.4-rko was working fine except for the switch problems
as mention before.


And finally a BIG thanks to R.K.Owen for all the work done on modules.


Andrew Watkins

Modules update to 3.0.6-rko

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

Modules has once again been updated, bug-fixed, and hopefully improved
with 3.0.6-rko.

This version is the start of "module versioning",  that is, providing
a way to use different versions of modules.  Exactly, in the same
way that modules allows the user to use different versions of a
given package.  To understand how this is used, be sure to read
the INSTALL file.  There are also some changes for the user & system dot
files (look at the etc/skel & etc/global files).

This version also fixes bugs with "module swap" and with "module init*"
introduced with 3.0.4-rko,  which was a major rewrite to use higher
level Tcl RegExp routines.

The files have been uploaded to sunsite.unc.edu (currently in /incoming/Linux
and it should in the listed directory in a few days).

Primary-site:   sunsite.unc.edu		/pub/Linux/utils/shell/
Alternate-site: ftp.scruz.net		/users/rkowen/public/modules/

Here are the changes:

Modules 3.0.6-rko
Wed Feb 16 09:06:34 PST 2000		R.K. Owen (rk...@ow...)
	* Changed "unsetenv" to allow an optional third argument to
	  set the env.var. to when unloading.
	* Fixed bugs with and upgraded the "module init*" commands.
	* Added a preliminary RPM .spec file ... some of the versioning
	  changes conflict with some RPM features.
Modules 3.0.5-rko	(not meant for public release)
Fri Jan 21 18:59:18 PST 2000		R.K. Owen (rk...@ow...)
	* Changed the behavior if "module" is called without an argument.
	  In addition to the error message it prints out the help text.
	* Fixed a problem with module swapping. A test needs to be
	  added to the testsuite.
	* Rewrote many of the init files & modified modules to allow
	  one level of env.var. expansion in the MODULEPATH & MODULERCFILE
	  environment variables.  The purpose is to allow the co-existence
	  of many versions of the module command.
	  Only this & successive versions will implement this.
	* Got the --with-logging configure option actually doing something
	  in the code.  The default is no syslog-ing.
	  However, this affects the tests ... expect 3 failures originating
	  from testsuite/modules.50-cmds/100-loglevel.exp .

Re: is switch working......

[<sve...@gm...>]

> I have just installed modules-3.0.4-rko and it looks very good
> and it seems to work with my old version of Modules(2.2Beta).
> 
> One think I get a core dump with the switch command
> 
> % module switch lang/5.0 lang/beta
> Segmentation Fault (core dumped)

Same here.

> I am using tcl8.0p1 which is a bit old....
> If no one else is having problems then I will down load a new version of tcl.

Well, I'm using 7.6something, so mine is even older.  It is supposed
to work with these versions, though...

Sven
-- 
 _    _  _____           Artificial Intelligence Unit
| |  | |/ /_ _|                                           University of Hamburg
| |__| ' < | |  phone:      +49 (0)40 42883-2576         Vogt-Koelln-Strasse 30
|____|_|\_\___| fax  :      +49 (0)40 42883-2572                D-22527 Hamburg
mailto:ut...@in...   www.informatik.uni-freiburg.de/~utcke

Re: Documentation or Papers on Modules?

[Don M. <dp...@sg...>]

Eric Roman wrote:
> 
> Does anyone have any of the original Modules paper?  I'm building a
> Red Hat RPM for the package.  I'd like to include some of the papers
> in the RPM.  I had found some on www.modules.org, but those have
> disappeared...
> 
> Eric
I think the original design document is in the doc directory of the
Modules 2.2 distribution (Modules-Paper.ps).
I have an html version if you are interested...
cheers,
Don

Modules misc. questions...

[Artz, D. R <dav...@in...>]

> Sorry if this has been addressed before but...
> 
> (1) What happened to www.modules.org (I've not been able to get to it for
> weeks, months maybe).
> (2) Has any one successfully compiled/run modules on HP (HPUX) and IBM
> Pentium II based Linux boxes?
> (3) What is latest version (I saw a blurb it was at 3.?) and where can one
> obtain it.
> 
> thanks!
> David Artz (in past lives, a happy modules customer :-). 

Re: Documentation or Papers on Modules?

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

The USENIX web site has the most recent one.  I believe they were all
published at LISA conferences.

The more recent paper is at

http://www.usenix.org/publications/library/proceedings/lisa96/full_papers/pwo/pwo.txt

The older one is from LISA V, which doesn't seem to be online.

-L


Once upon a time (like on Feb 14, 2000), Eric Roman wrote:
> 
> Does anyone have any of the original Modules paper?  I'm building a
> Red Hat RPM for the package.  I'd like to include some of the papers
> in the RPM.  I had found some on www.modules.org, but those have
> disappeared...
> 
> Eric
> 

Documentation or Papers on Modules?

[Eric R. <er...@lb...>]

Does anyone have any of the original Modules paper?  I'm building a
Red Hat RPM for the package.  I'd like to include some of the papers
in the RPM.  I had found some on www.modules.org, but those have
disappeared...

Eric

is switch working......

[Andrew W. <an...@dc...>]

I have just installed modules-3.0.4-rko and it looks very good
and it seems to work with my old version of Modules(2.2Beta).

One think I get a core dump with the switch command

% module switch lang/5.0 lang/beta
Segmentation Fault (core dumped)

I am using tcl8.0p1 which is a bit old....
If no one else is having problems then I will down load a new version of tcl.

Thanks

Andrew Watkins

modules-3.0.4rko & Tcl 8.2.3

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

Hello All - I think is considered a must-have upgrade on modules-3.0rko.
It wasn't easy, but I managed to update modules to compile with
Tcl 8.2.x!  The modules-3.0beta code, for reasons I don't know, used
the Tcl low-level regexp & glob code.  This is why it required that
the Tcl header files tclRegExp.h & tclInt.h to be made available for
the modules compilation.  This was never comfortable for me.
Anyways, I rewrote all the regexp calls to use a higher level Tcl
routines.  The downside is that there may be (are) defects that need to
be exorcized.  It passes all the established tests.  The upside
is that it's now largely independent of Tcl version.  (I checked
the Tcl 7.5 sources and it should work with them, but I couldn't
build the Tcl 7.5 libraries on my system to test this assertion.)
And it no longer requires tclRegExp.h & tclInt.h.

I've incorporated helpful suggestions (code patches), and also fixed
a Y2K problem in --long listings.

Here's the relevant ChangeLog entry:
	* Rewrote a lot of the calls to low level Tcl RegExp
	  routines, which required direct access to the tclRegExp.h
	  header file.
	  Used higher level Tcl routines to accomplish the same.
	  The net result is that modules should be configurable under
	  any version of Tcl > 7.4 (not tested).
	* Rewrote a reference to a low level Tcl glob routine, which
	  required direct access to the tclInt.h header file.
	  Used the $HOME environment instead.
	* Mean-time hack to support multiple subdirectories for the
	  "avail" option.
	* Fixed the long listings to be Y2K OK.
	* Added a version option to print out the module version ...
	  for future automated scripting.
	* Some documentation clean-up.
	* Removed all references to PARSEABLE_ERRORS in config.h
	  and configuration ... since it's not used at all.
	* Modified init files because some systems treat undefined
	  variables in sh/ksh/bash/zsh as errors and terminates login
	  process (Thanks to Martin Jost).
	* Modified Tcl_HashTable declaration initialization to 
	  assignment, because some ANSI C compilers complain
	  (Thanks to Martin Jost).

To download the code anonymous ftp to metalab.unc.edu in /incoming/Linux
for now and /pub/Linux/utils/shell/ in a couple of days.  Or go to
ftp.scruz.net in /users/rkowen/public/modules/ .

I welcome suggestions and treasure code patches.  "Code talks ... everything
else walks."

	R.K.

+-----------------------+----------------------------------+
| R.K.Owen,PhD          | rk...@ow...                 |
| KooZ Software         |                                  |
| NERSC/LBNL            | rk...@ne...   (510)486-7556 |
+-----------------------+----------------------------------+

Re: modules3.0.3-rko - some remarks and diffs

[JONATHAN W M. <Jon...@lm...>]

Jost Martin wrote:

> use.own                                              100/01/11 13:47:16
>
> Oops - Y2K was here ! Is this a problem of tcl8.0.4 or of module itself ?
> (Ok, this problem is really minor)
>

This is a pretty simple problem to fix.  Here is the patch I made to
Modules-3.0pre.  I converted to a four-digit year, and added 1900 to
tm->tm_year.  If you look at the man pages (Solaris at least) you will see that
tm_year is defined as the number of years since 1900.  Another possible, and
unrelated change would be to replace gmtime() with localtime().

*** ModuleCmd_Avail.c.orig      Mon Jan  3 11:13:43 2000
--- ModuleCmd_Avail.c   Mon Jan  3 11:14:07 2000
***************
*** 1495,1502 ****
                 **/

                if((struct tm *) NULL != (tm = gmtime( &stats.st_mtime))) {
!                   sprintf( buffer, "%02d/%02d/%02d %2d:%02d:%02d",
!                       tm->tm_year, tm->tm_mon + 1, tm->tm_mday, tm->tm_hour,
                        tm->tm_min, tm->tm_sec);
                    timestr = buffer;

--- 1495,1502 ----
                 **/

                if((struct tm *) NULL != (tm = gmtime( &stats.st_mtime))) {
!                   sprintf( buffer, "%04d/%02d/%02d %2d:%02d:%02d",
!                       tm->tm_year + 1900, tm->tm_mon + 1, tm->tm_mday,
tm->tm_hour,
                        tm->tm_min, tm->tm_sec);
                    timestr = buffer;




--
Jonathan Miner - Lockheed Martin EIS/SAI
LM-Xpress: jon...@lm...
Phone: 603 885 UNIX - Fax: 603 885 3850
USmail: PO Box 868, NCA01-3719, Nashua, NH 03061-0868

modules3.0.3-rko - some remarks and diffs

[Jost M. <Mar...@ic...>]

Hello,

first of all a big "Thank You !" to R.K.Owen for taking care of modules !
I downloaded modules-3.0.3-rko and installed it on HPUX 10.20. (usning HP
ANSI C compiler)

Here are some remarks and diffs:
- I first tried tcl8.3.2 but failed. (It needs some more .h-files from the
tcl-dsitrib.; but finally still fails)
  I saw a posting, that 3.0.2 is suposed to compile with tcl8.0.x. Is this
still correct for 3.0.3 ?
  (I found nothing contrary in ChangeLog)
  I finally used tcl8.0.4


- Using tcl8.0.4 I get the following module avail output:
- Package -----------+- Release -+- Versions -------+- Last mod. ------
/pd/Modules3.0.3/modulefiles:
3.0.3-rko                                            100/01/11 13:47:16
dot                                                  100/01/11 13:47:16
module-info                                          100/01/11 13:47:16
modules                                              100/01/11 13:47:16
null                                                 100/01/11 13:47:16
use.own                                              100/01/11 13:47:16


Oops - Y2K was here ! Is this a problem of tcl8.0.4 or of module itself ?
(Ok, this problem is really minor)


- When I tried to compile, I got problems with utility.c. This file tries to
initialize arrays with assignments.
This isn't supported by HP ANSI C.

I changed utility.c:
293,295c293
<     Tcl_HashTable	*table[] = { setenvHashTable, unsetenvHashTable,
< 				     aliasSetHashTable, aliasUnsetHashTable,
< 				     NULL },
---
>     Tcl_HashTable	*table[5],
297a296,302
>     table[0] = setenvHashTable;
>     table[1] = unsetenvHashTable;
>     table[2] = aliasSetHashTable;
>     table[3] = aliasUnsetHashTable;
>     table[4] = NULL;
> 
> 
362,364c367
<     Tcl_HashTable	*table[] = { setenvHashTable, unsetenvHashTable,
< 				     aliasSetHashTable, aliasUnsetHashTable,
< 				     NULL };
---
>   Tcl_HashTable	*table[5];
365a369,374
>   table[0] = setenvHashTable;
>   table[1] = unsetenvHashTable;
>   table[2] = aliasSetHashTable;
>   table[3] = aliasUnsetHashTable;
>   table[4] = NULL;
>   
452,455c461,462
<     Tcl_HashTable	 *oldTable[] = { setenvHashTable, unsetenvHashTable,
< 					 aliasSetHashTable,
aliasUnsetHashTable,
< 					 NULL },
< 			**o_ptr, **n_ptr,
---
>     Tcl_HashTable	*oldTable[5],
>       			**o_ptr, **n_ptr,
457a465,470
>     oldTable[0] = setenvHashTable;
>     oldTable[1] = unsetenvHashTable;
>     oldTable[2] = aliasSetHashTable;
>     oldTable[3] = aliasUnsetHashTable;
>     oldTable[4] = NULL;
> 
654c667,670
<     Tcl_HashTable	*table[] = { setenvHashTable, unsetenvHashTable };
---
>     Tcl_HashTable	*table[2];
> 
>     table[0] = setenvHashTable;
>     table[1] = unsetenvHashTable;
743,744c759
< 
<     Tcl_HashTable	*table[] = { aliasSetHashTable, aliasUnsetHashTable
};
---
>     Tcl_HashTable	*table[2];
766a782,784
> 
>     table[0] = setenvHashTable;
>     table[1] = unsetenvHashTable;

- When using modules3.0.3 the first time, I got locked out of my account,
due to a known bug with the init-Files:
  they do somehing like 
  if  [ "$LOADEDMODULES" = "" ]; then ..
  if LOADEDMODULES isn't defined and the shell is set to 'treat references
to undef. vars as errors' (as mine is)
  the login fails.

This has to be changed:
(Yielding "" for undef. vars.)
sh.in:
  7c7
< if [ "$LOADEDMODULES" = "" ]; then
---
> if [ "${LOADEDMODULES:-}" = "" ]; then
12c12
< if [ "$MODULEPATH" = "" ]; then
---
> if [ "${MODULEPATH:-}" = "" ]; then

ksh.in:
7c7
< if [ "$LOADEDMODULES" = "" ]; then
---
> if [ "${LOADEDMODULES:-}" = "" ]; then
12c12
< if [ "$MODULEPATH" = "" ]; then
---
> if [ "${MODULEPATH:-}" = "" ]; then

bash.in:
7c7
< if [ "$LOADEDMODULES" = "" ]; then
---
> if [ "${LOADEDMODULES:-}" = "" ]; then
12c12
< if [ "$MODULEPATH" = "" ]; then
---
> if [ "${MODULEPATH:-}" = "" ]; then

I don't know what is needed for the other shells !

I hope this comments will help improving module. Thanks for your work !

Martin Jost

Re: RKO modules

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

 * The Locating Modulefiles section states that every directory is searched to find modulefiles and can have an arbitrary number of sub-directories.  This works as described.  However, the 'module list' and 'module avail' commands do not support reporting any more than the last two levels of this sub-directory structure.  As such, these two commands are broken.

I agree with this comment about 3.0.2 too; this is inconsistent with 2.2beta and the main reason we are still using 2.2beta.

I also have one change I would like to see.  It would be nice if a prepend path would remove and then prepend if the directory is already in the PATH.  I made this change in the 3.0.2 source that I downloaded, but if others agreed it would be nice to see it in the distributed source (maybe as a compile option).

Thanks,

- Mark

>>> "David C. Mores" <Dav...@lm...> 01/03/00 12:50PM >>>

"R.K. Owen Ph.D." wrote:

> Hello one & all:
> Being totally unaware that there is any organized effort to develop the modules
> software.  I've posted the following to the comp.os.linux.announce (c.o.l.a)
> news group announcing the availability of modules for linux.
>
> Anyways, I placed the sources under CVS and have been rewriting, fixing,
> adding to, and organizing the sources.  Once I figure out how
> to allow CVS server read-only access I'll announce that availibility
> to this list.
>
> I welcome any help & comments.
>         R.K.

 


     For many of you, two levels may be adequate, but our shop has been using three levels of modulefile directory structure for the past seven (7) years.   Modules 2.2beta handles this correctly.  We arrange this as the Package level, Release level, and local Revision level.  So for a package like Netscape, we have release 4.7, revision 'a' - module load netscape/4.7/a.  Any subsequent local changes setup environment to the initial release would be handled smoothly with a new module file
     revision 'b' - module load netscape/4.7/b.  Since a .version  file can be used to control the default at the release and revision levels, users can be isolated from changes to the default version (4.5, 4.6, 4.7...) and any local revisions (a,b,c...) when they simply 'module load netscape'.  Migration to new releases and levels is handled smoothy.  If trouble develops, this can be backed out smoothy too.

     So the bottom line here is that the modules 'list' and 'avail' need to be fixed to work with whatever number of sub-directories or levels exist to be in line with how the other module commands work.

   * The 'module -l list' command headings for 'Versions' is  incorrect in my opinion.  This is not really a column for the version, but the 'default' and other 'module-version' or 'module-alias' symbols defined in the modulefiles.  The source code (ModuleCmd_Avail.c in the print_aligned_files function) references this data as 'symbols'.  So 'Versions' should be changed to something more appropriate like 'Symbols'.
   * When the 'module list' and 'module avail' commands are fixed as recommended above, they must handle listing the 'default' flag or symbol appropriately at each level of module sub-directory structure.
   * The 'module-version' modulefile statement left me confused for some time with the words 'This command should be placed in one of the modulecmd rc files in order to provide shorthand invocations of frequently used module file names'.  I thought this would allow me to specify some 'alias_name' for a module file so that I could 'module load alias_name'.  Apparently, not so; these names only seem to apply within the context for the modulefiles.  So, aside from the special 'default'
     version-name, I am somewhat puzzled as to how to best take advantage of this modulefile statement.  I think some additional discussion and examples should be supplied in the man pages to further clarify the (intended) use of the module-version statement.
   * The 'module-alias' statement, as well, needs an expanded clarification of function, some discussion and examples of use.

That's enough for now.

Enjoy,
Dave

RKO modules

[David C. M. <Dav...@lm...>]

"R.K. Owen Ph.D." wrote:

> Hello one & all:
> Being totally unaware that there is any organized effort to develop the modules
> software.  I've posted the following to the comp.os.linux.announce (c.o.l.a)
> news group announcing the availability of modules for linux.
>
> All I know is that I had to overcome several major hurdles to get
> modules working on Linux (or any other system), especially starting
> with the 3.0beta sources, which had the features I wanted.  I checked
> with the www.modules.org webmaster & several others to see if there
> was any active work.  Nothing active that I know of.
>
> Anyways, I placed the sources under CVS and have been rewriting, fixing,
> adding to, and organizing the sources.  Once I figure out how
> to allow CVS server read-only access I'll announce that availibility
> to this list.
>
> I welcome any help & comments.
>         R.K.

Thanks for your work and the work of others on modules 3.0.2.  It is quite a useful package that has not received the credit it deserves.

I have also been successful in compiling the RKO modules version on Solaris 2.7, HP-UX 10.20 and SunOS 4.1.4.  The use of the configure utility make this so much easier than past versions of modules.

I do have some comments and suggestions:

   * The man page on modulefiles has at least two references to .modulesrc in the section on Locating Modulefiles.  The reference should be .modulerc (i.e. - drop the 's').  This had me running around in circles until I checked the source code.
   * The Locating Modulefiles section could use some rewrite to clarify the english.
   * The Locating Modulefiles section states that every directory is searched to find modulefiles and can have an arbitrary number of sub-directories.  This works as described.  However, the 'module list' and 'module avail' commands do not support reporting any more than the last two levels of this sub-directory structure.  As such, these two commands are broken.




     For many of you, two levels may be adequate, but our shop has been using three levels of modulefile directory structure for the past seven (7) years.   Modules 2.2beta handles this correctly.  We arrange this as the Package level, Release level, and local Revision level.  So for a package like Netscape, we have release 4.7, revision 'a' - module load netscape/4.7/a.  Any subsequent local changes setup environment to the initial release would be handled smoothly with a new module file
     revision 'b' - module load netscape/4.7/b.  Since a .version  file can be used to control the default at the release and revision levels, users can be isolated from changes to the default version (4.5, 4.6, 4.7...) and any local revisions (a,b,c...) when they simply 'module load netscape'.  Migration to new releases and levels is handled smoothy.  If trouble develops, this can be backed out smoothy too.

     So the bottom line here is that the modules 'list' and 'avail' need to be fixed to work with whatever number of sub-directories or levels exist to be in line with how the other module commands work.

   * The 'module -l list' command headings for 'Versions' is  incorrect in my opinion.  This is not really a column for the version, but the 'default' and other 'module-version' or 'module-alias' symbols defined in the modulefiles.  The source code (ModuleCmd_Avail.c in the print_aligned_files function) references this data as 'symbols'.  So 'Versions' should be changed to something more appropriate like 'Symbols'.
   * When the 'module list' and 'module avail' commands are fixed as recommended above, they must handle listing the 'default' flag or symbol appropriately at each level of module sub-directory structure.
   * The 'module-version' modulefile statement left me confused for some time with the words 'This command should be placed in one of the modulecmd rc files in order to provide shorthand invocations of frequently used module file names'.  I thought this would allow me to specify some 'alias_name' for a module file so that I could 'module load alias_name'.  Apparently, not so; these names only seem to apply within the context for the modulefiles.  So, aside from the special 'default'
     version-name, I am somewhat puzzled as to how to best take advantage of this modulefile statement.  I think some additional discussion and examples should be supplied in the man pages to further clarify the (intended) use of the module-version statement.
   * The 'module-alias' statement, as well, needs an expanded clarification of function, some discussion and examples of use.

That's enough for now.

Enjoy,
Dave

Re: Current release?

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

I can agree with that.  I'd like to see modules be maintained and
updated, we find them very useful here.

- Mark

>>> "R.K. Owen Ph.D." <rk...@ow...> 12/21/99 11:08AM >>>
I've been maintaining a version that I've uploaded
to http://metalab.unc.edu/pub/linux/utils/shell/ named
modules-3.0.2-rko.tar.gz.  It has all the functionality that was
promised
in the original documentation that I'm aware of.  It requires Tcl 8.0.x
&
one of my tasks is to allow it to compile with Tcl > 8.0.  If you use
Red
Hat 6.x  Linux then you need a patch (which will be in the 3.0.3
release).

I've uploaded this to {www|ftp}.modules.org, but, as usual, I've
received
no response at all.
Maybe it's time to reassign the modules.org domain somewhere else and
let the modules work progress.

R.K.
+-----------------------+----------------------------------+
| R.K.Owen,PhD          | rk...@ow...   (408)377-5373 |
| KooZ Software         |                                  |
| NERSC/LBNL            | rk...@ne...   (510)486-7556 |
+-----------------------+----------------------------------+