Versions tested: 3.1.1, 3.1.2

When a modulefile itself loads a modulefile, the
second-level modulefile doesn't have its .version file
loaded during a switch command. Seems to work correctly
during module load and module unload commands.

With attached test files, do the following:

% module load Proj/A
% module switch Proj Proj/B

Note the following messages:

opus:modulefiles> module switch Proj Proj/B
Proj/A: mode is switch1
Proj/A: Info exists TEST_VER == 1
.version: setting TEST_VER to 1
Test/1: mode is switch1
Proj/B: mode is switch2
Proj/B: Info exists TEST_VER == 1
Test/1: mode is switch2
Proj/A: mode is switch3
Proj/A: Info exists TEST_VER == 1
Test/1: mode is switch3

There are two problems in the above debug messages:

1. There should be a ".version: setting TEST_VER to 2"
   below "ProjB: Info exists TEST_VER == 1" indicating
   that the "module load Test" command in the B modulefile
   loaded the .version file, but there is none so the
   wrong version was loaded.

2. The "ProjB: Info exists TEST_VER == 1" line should
   indicate that TEST_VER == 2, but it incorrectly shows

3. If a "module load Proj/B" is done, you will see that
   the "setenv TEST_VER 2" results in $env(TEST_VER) being
   set properly, but it isn't during a switch as shown
   above.

Thanks,

• Leo Butler
  mailto:[email protected]

Reported by: *anonymous

When using the modules software on a bourne shell,
aliases are turned into this shell code:

Module:
alias ct cleartool

Output of modulecmd:
ct() {
cleartool;
}

This output should IMHO read:
ct() {
cleartool ${1+"$@"};
}

This allows saying e.g.

ct -ver
ct co .

and the like. The current code drops all arguments...

Thanks & best regards,

Marek Rouchal
marek dot rouchal at infineon dot com

Reported by: *anonymous

Hi
We're using the C version, previously 3.1.6 and now 3.2.3

We have a module with 102 versions and we find
'modulecmd' crashes.

I see there is code to realloc but I think there is a
problem in it.

As a workaround I increased SRCFRAG and
FILE_LIST_SEGM_SIZE, made the size of _file_list_buffer
depend on FILE_LIST_SEGM_SIZE, and changed two
instances of '100' to SRCFRAG.

The above touches just ModuleCmd_Avail.c and
locate_module.c, but has introduced other reliability
problems.

Please let me know if you need more information.

Ed

Reported by: edspittles

Hello,

The module(1) command really should have a significant return value, so it can be used in scripts. For instance
when trying to load a non-existant module the command
prints:
ModuleCmd_Load.c(200):ERROR:105: Unable to locate a modulefile for 'doesnotexist'
but still returns 0.
How to solve it:
If modulecmd detects an error, it should print
"false" as the last statement to stdout, and since the
output is evaluated by the shell, the return
value will be non-zero.

Thanks,

Peter

Reported by: *anonymous

Some checks for return codes are missing.

Examples:
Would you like to add more error handling for return values from "strdup" like in the function "store_hash_value" and from "fprintf" in the function "ModuleCmd_List"?
http://modules.cvs.sourceforge.net/modules/modules/ModuleCmd_List.c?revision=1.7&view=markup
http://modules.cvs.sourceforge.net/modules/modules/utility.c?revision=1.25&view=markup

Reported by: elfring

I was having trouble with the init/perl such that I was getting sed and awk errors. Instead of debugging sed and awk, I decided to replace that section with native perl code.

Reported by: gearspring

Hi,

We have noticed that some module commands return an error message which does not have any meaning to the actual error. EG:

module load dot
module purge
module purge (Again, straight after the first one)
ModuleCmd_Purge.c(112):ERROR:107: 'MODULEPATH' not set

So the error states that MODULEPATH isn't set, however the actual issue is the environment variable LOADEDMODULES isn't set. Looking at some of the source code, this happens a couple of times (Referring to ERR_MODULE_PATH as the error which checking LOADEDMODULES).

I have attached a simple patch which adds another error code called ERR_LOADEDMODULES and have updated a couple of the cmd files to reflect this.

Reported by: *anonymous

Older versions of tclsh give

wrong # args: should be "regsub ?switches? exp string subSpec varName"
while executing
"regsub {$[^:]+:\s*(\S+)\s*$}
{$Revision: 1.132 $} {\1}"

This same problem occurs other places. The attached fixes these;
please check I got them all correctly.

Reported by: wsnyder2

When setting up modulefiles a default module version
setting is ignored if the modulefiles concerned are
defined in subdirectory of level 2.

In other words: Assume we have three modulefiles where
the lowest version should be the default one to be
loaded if the version is omitted on 'module load':

foo/bar/1.0(default)
foo/bar/2.0
foo/bar/3.0

Regardless of any "ModulesVersion" or "module-version"
setting the highest lexicographically sorted
modulefile under the directory foo/bar is loaded on
'module load foo/bar', i.e. foo/bar/3.0 is loaded.

The problem does not occur if the directory hierarchy
level "bar" is omitted in the definition.

Problem occurs with Environment Modules 3.1.6-3.2.3
(and is imho not handled in the testsuite yet).

Steps to reproduce the problem:
% mkdir tmp
% cd tmp
% mkdir -p foo/bar
% cat < foo/bar/1.0
#%Module -- tcl --
EOF
% cp -p foo/bar/1.0 foo/bar/2.0
% cp -p foo/bar/1.0 foo/bar/3.0
% cat < .modulerc
#%Module -- tcl --
module-version foo/bar/1.0 default
EOF
% module use $PWD
% module avail
--------------- tmp ---------------
foo/bar/1.0(default) foo/bar/2.0 foo/bar/3.0
% module purge
% module load foo/bar
% module list # we expect foo/bar/1.0 to be loaded
Currently Loaded Modulefiles:

1. foo/bar/3.0

% ### Hey! That's wrong! foo/bar/1.0 should have been
loaded!
% ### Try something else:
% rm -f .modulerc
% cat < foo/bar/.version
#%Module -- tcl --
set ModulesVersion 1.0
EOF
% module avail
--------------- tmp ---------------
foo/bar/1.0 foo/bar/2.0 foo/bar/3.0
% ### No "(default)" tag any more - as expected.

% module purge; module load foo/bar
% module list # we expect foo/bar/1.0 to be loaded now!
Currently Loaded Modulefiles:

1. foo/bar/3.0

% ### Did not help! foo/bar/1.0 not loaded!
% ### Try something else:
% rm -f foo/bar/.version
% cat < foo/.modulerc
#%Module -- tcl --
module-version foo/bar/1.0 default
EOF
% module avail
--------------- tmp ---------------
foo/bar/1.0(default) foo/bar/2.0 foo/bar/3.0
% module purge; module load foo/bar
% module list # we expect foo/bar/1.0 to be loaded
Currently Loaded Modulefiles:

1. foo/bar/3.0

% ### Did not help either! foo/bar/1.0 still not
loaded!

Reported by: *anonymous

Hi again,

Configuring the tool with the following options will fail on the build
unless the following is added to main.c

#if WITH_DEBUGGING_MODULECMD
static char _proc_ModuleCmd_Help[] = "ModuleCmd_Help";
#endif

Configure options:

./configure --prefix=/home/sklass/mod-dev/modules --enable-
versioning --enable-shell-funcs
--enable-shell-alias --enable-version-magic --enable-
logging=yes
--with-tcl=/home/sklass/mod-dev/modules/lib --without-tclx
--with-split-size=2046
--with-debug=yes
--with-log-facility-verbose=stderr
--with-module-path=/smsc/tools/modulefiles/production/
tools::/smsc/tools/modulefiles/production/projects
--with-version-path=/home/sklass/mod-dev/modules/versions

Reported by: rhodium

If you use an environment variable in your modulefile, like

setenv foo $env(HOME)/bar

and you have that modulefile loaded when you type

% module update

The value of $foo will have a carriage return before
the '/bar'.

I think this is a bug on line 167 of ModuleCmd_Update.c
where the pointer is advanced past the newline before
the null is added. I think you meant to replace the
newline with the null character.

Reported by: ecwhitney

In Modules 2.2beta, when I unload a package, the LOADEDMODULES env var
gets reset as I would expect. However, in Modules 3.1.0b, the
LOADEDMODULES env var does not get reset, and I can't successfully switch
to another module, since it complains!

spark,> module unload hercules
spark,> module load hercules
hercules/1999.2(29):ERROR:150: Module 'hercules/1999.2' conflicts with the
currently loaded module(s) 'hercules/1999.2.1'
hercules/1999.2(29):ERROR:102: Tcl command execution failed: conflict
hercules

Am I missing something, or is the module command really broken? I looked
at the output of modulecmd directly, and I can see that it sets things
like PATH, MANPATH and LMFILES, but not LOADEDMODULES when I unload.

Any ideas?

-Mark

Reported by: rminsk

Lets say I have two modules: prman/3.8c and prman/3.9. I need a command
that will tell me what version of prman I have loaded. For example could
"module list prman" return prman/3.9 if I have prman/3.9 loaded?

Reported by: rminsk

I was having trouble with the init/perl such that I was getting sed and awk errors. Instead of debugging sed and awk, I decided to replace that section with native perl code.

Reported by: *anonymous

We are getting a repeated error when we attempt to load more than two modules at the same time. Sequential loads are not a problem.

Modules 3.2.5
RHEL4 and TCL 8.4

the error we get:

*** glibc detected *** free(): invalid pointer: 0x0000000000557db8 ***

sementation fault

Reported by: *anonymous

Hi.

We have just started using modules on our linux cluster and discovered that jobs using bash in the queuing system did not have the module command defined. After some digging we found that the module command is a function defined in the file /opt/Modules/default/init/bash, but this function is not exported to the environment if the initial shell is not a login shell (which is the case for jobs in our batch system).

We are able to hack around this by injecting the necessary export command at installation time, but it would be nice if this could make it into the mainline source:

insert export -f module at line 12

sed -i '12iexport -f module' /opt/Modules/default/init/bash

Our operating enviroment:
Rocks Cluster Distribution 4.3, aka CentOS4/RedHat EL 4
torque-2.1.8 (a derivative of the openpbs batch system)

(I'm reporting this as a feature request, as I'm not sure if this is a bug or a feature;-)

Best regards and thanks for a great tool,
r.

Reported by: roydra

modules is not using .version files in subdirectories.

If I use the MODULEPATH /opt/Modules/modulefiles/misc:/opt/Modules/modulefiles/office and place modulefiles in /opt/Modules/modulefiles/misc/dir1 and /opt/Modules/modulefiles/misc/dir1/dir2 only the file /opt/Modules/modulefiles/misc/dir1/.version is interpreted by modules. The file /opt/Modules/modulefiles/misc/dir1/dir2/.version is ignored.

Reported by: *anonymous

Hi,

Attempting to use the syslog reporting feature in the tool.

Using the following configuration will cause a core file to be created
each time an eval modulecmd is issued.

./configure --prefix=/home/sklass/mod-dev/modules --enable-
versioning --enable-shell-funcs
--enable-shell-alias --enable-version-magic --enable-
logging=yes
--with-log-facility-verbose=stdout
--with-log-facility-info=local7.notice
--with-log-facility-debug=local7.notice
--with-log-facility-trace=local7.notice
--with-log-facility-warn=local7.notice
--with-log-facility-problem=local7.notice
--with-log-facility-error=local7.notice
--with-log-facility-fatal=local7.notice
--with-log-facility-panic=local7.notice
--with-trace-load=yes
--with-trace-unload=yes
--with-trace-switch=yes
--with-trace-disp=yes
--with-trace-list=yes
--with-trace-avail=yes
--with-trace-help=yes
--with-trace-init=yes
--with-trace-use=yes
--with-trace-unuse=yes
--with-trace-update=yes
--with-trace-purge=yes
--with-trace-clear=yes
--with-trace-whatis=yes
--with-trace-apropos=yes
--with-tcl=/home/sklass/mod-dev/modules/lib --without-
tclx --with-split-size=2046
--with-module-path=/smsc/tools/modulefiles/production/
tools::/smsc/tools/modulefiles/production/projects

I have tried variations on this config but local7.notice never gets
logged to.

FYI: Redhat RHEL3.0 Linux box

Thanks Steven

Reported by: rhodium

On Solaris platform the sed that sets MODULESPATH results in a command garbled error. This is a result of a semicolon missing from the end of the command:

setenv MODULEPATH sed -n 's/[ I#].*$//g; /./H; $ { x; s/^\n//; s/\n/:/g; p; }' "${MODULESHOME}"/init/.modulespath

Note the semicolon after the p

Reported by: *anonymous

This is not a BUG. The file init/completion.in is missing from the 3.2.7 tarballs (either gz or bz2), but Makefile.in dictates the need for it.I would be good to include them.

Reported by: madskaddie

Hello,
The link command for modulecmd puts -ltcl8.5 before the object files on the command line, but it should be placed after that, according to
http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#index-Libraries-945:

-llibrary
It makes a difference where in the command you write this option; the linker searches and processes libraries and object files in the order
they are specified. Thus, foo.o -lz bar.o' searches library z' after file foo.o but before bar.o. If bar.o refers to functions in `z', those functions may not be
loaded.

therefore the Makefile should be modified. The following diff illustrates the required change for the top level Makefile in version 3.2.7b:

178c178
< LIBS = -ldl -lm -lX11 -lnsl -lsocket

LIBS = -ldl -lm -lX11 -lnsl -lsocket -ltcl8.5

compiler Version is gcc 3.3, system is Interix 6.1 (Windows Services for Unix).

Regards,

Peter

Reported by: hotzenplotz

It is possible that a PATH is longer than the computed
(strlen( argv[2]) + 1) in cmdPath.c at line 212 if
argv[2] contains something like $APPPATH/bin. The
environment variable may be sometimes longer than the
reserved space resulting in a segmentation fault.

Reported by: *anonymous

Valgrind reported two kinds of errors running 'modulecmd bash purge'. The first error was the use of strcpy() with overlapping source and destination. This can be fixed with this patch to 3.2.5:

*** /tmp/modules-3.2.5/cmdPath.c 2007-02-13 21:38:21.000000000 -0800
--- cmdPath.c 2007-03-21 11:55:05.000000000 -0700

*** 792,798 ****
** We must be in SW_STATE3 or not in SW_STATE at all.
** Removing the marker should be just like removing any other path.
**/
! strcpy( startp + start_offset, endp);

    /**
     **  Cache the set.  Clear the variable from the unset table just

--- 792,798 ----
** We must be in SW_STATE3 or not in SW_STATE at all.
** Removing the marker should be just like removing any other path.
**/
! memmove( startp + start_offset, endp, strlen(endp) + 1);

    /**
     **  Cache the set.  Clear the variable from the unset table just

The second set of errors involved use of allocated memory after it was freed. This was traced to ReturnValue's reuse of the results of Tcl_RegExpCompile(), whose current documentation says not to do this. The following patch restructures ReturnValue to always set em_result, one way or the other, and to repeat the call to Tcl_RegExpCompile() as needed.

Fixing this bug got rid of "glibc error - free(): invalid pointer" errors on at least one system.

Reported by: daletalcott

Similar to the previous update of init/perl to remove awk and sed, here's a new version of python.in that fixes that and also uses subprocess.Popen instead of os.popen.

Also, module() previously made assumptions about the number of arguments, etc. That prevented things like switching modules (which requires 3 arguments). The new version is still backwards compatible and can have a list as the first argument to module() or it can accept an arbitrary number of string arguments (because it seems more useful to be able to say module("switch", "foo/1.0", "foo/2.0") instead of constructing a list to pass in).

Reported by: *anonymous

I experience a segmentation fault (Solaris) when doing
'module update' and it's because of variables with long
values in the modulesbeginenv file. There is an error
when the length of the values approach (or exceed)
UPD_BUFSIZE.

(ModuleCmd_Update.c) checks the size of the read value
and allocates a new buffer which is larger than the
first one, but it never copies the read data to it, and
it never moves the pointer to use the new buffer.

Attached is my updated ModulesCmd_Update.c file. Please
include the changes in the next release of Modules.

Reported by: olofa

line 341 of error.c should complain about LOADEDMODULES instead of LOADMODULES

341c341
< { ERR_ENVVAR, WGHT_FATAL, "The environment variables LOADMODULES and LMFILES have inconsistent lengths." }

{ ERR_ENVVAR,       WGHT_FATAL, "The environment variables LOADEDMODULES and _LMFILES_ have inconsistent lengths." }

Reported by: schumack

Compiling modules 3.2.2 and 3.2.3 with debugging enabled fails because _proc_stringer is undeclared in utility.c:2785. Can fix by declaring _proc_stringer in the secion in the WITH_DEBUGGING_UTIL_2 section.

Reported by: mahlstrom

Hello Modules,

The file modulefiles/modules contains the line;

prepend-path MANPATH $modroot/man

This should point to $modroot/share/man

At the moment man module does not load!

HTH, HAND

Lev Lafayette

Reported by: levlafayette

The current implementation of init area files for shells depends on sed using \t. \t is not portable across many implementation of sed. Reference:

http://www.gnu.org/software/sed/manual/html_node/Regular-Expressions.html
\char
Matches char, where char is one of $, *, ., [, , or ^. Note that the only C-like backslash sequences that you can portably assume to be interpreted are \n and \; in particular \t is not portable, and matches a `t' under most implementations of sed, rather than a tab character.

Suggest using a tab character, or similar construct. Do not use POSIX implementation as again that may not be portable.

Without a change Solaris 10 and 9 both pring a command garbled when sourcing the init/shell area.

Reported by: *anonymous

While experimenting a bit on John's case example, I noticed
a problem when the LMFILES string length was going to get
bigger than 960 characters; modules splits the variable into
two, _LMFILES_000 and _LMFILES_001. Once this happens, any
unload operation won't be reflected in these environment
variables.

Additionally, performing a switch operation results in a new
LMFILES variable being created, so modules only reports the
switched module as being loaded.

I can "cure" modules simply by fixing the environment vars.
Otherwise, continuing to attempt additional module commands
can result in a core dump.

This is occurring on a UltraSPARC 10 running SunOS 5.7
Generic_106541-07 with tcsh 6.07.02.

Any thoughts?

Reported by: rminsk

gcc -c -I.. -I. -I/usr/local/include -I/usr/include/X11 -
g -
DINSTPATH=&quot;/home/se046969/bragrej/modules/appmodu
le&quot; ModuleCmd_Avail.c
In file included from /usr/local/lib/gcc-lib/sparc-sun-
solaris2.4/2.7.2.2/include/time.h:90,
from ModuleCmd_Avail.c:44:
/usr/include/sys/siginfo.h:74: parse error before
pthread_attr_t' /usr/include/sys/siginfo.h:74: warning: no semicolon at end of struct or union /usr/include/sys/siginfo.h:76: parse error before }'
In file included from /usr/local/lib/gcc-lib/sparc-sun-
solaris2.4/2.7.2.2/include/time.h:90,
from ModuleCmd_Avail.c:44:
/usr/include/sys/siginfo.h:284: parse error before
int32_t' /usr/include/sys/siginfo.h:284: warning: no semicolon at end of struct or union /usr/include/sys/siginfo.h:284: warning: no semicolon at end of struct or union /usr/include/sys/siginfo.h:286: parse error before }'
/usr/include/sys/siginfo.h:286: warning: data definition
has no type or storage class
/usr/include/sys/siginfo.h:288: parse error before }' /usr/include/sys/siginfo.h:288: warning: data definition has no type or storage class /usr/include/sys/siginfo.h:415: parse error before int32_t'
/usr/include/sys/siginfo.h:415: warning: no semicolon at
end of struct or union
/usr/include/sys/siginfo.h:415: warning: no semicolon at
end of struct or union
/usr/include/sys/siginfo.h:416: conflicting types for
__rctl' /usr/include/sys/siginfo.h:285: previous declaration of __rctl'
/usr/include/sys/siginfo.h:418: parse error before }' /usr/include/sys/siginfo.h:418: warning: data definition has no type or storage class /usr/include/sys/siginfo.h:420: parse error before }'
/usr/include/sys/siginfo.h:420: warning: data definition
has no type or storage class
/usr/include/sys/siginfo.h:424: parse error before
k_siginfo_t' /usr/include/sys/siginfo.h:424: warning: no semicolon at end of struct or union /usr/include/sys/siginfo.h:428: parse error before }'
/usr/include/sys/siginfo.h:428: warning: data definition
has no type or storage class
*** Error code 1
make: Fatal error: Command failed for target
`ModuleCmd_Avail.o'

Reported by: qrabenj

On the man page http://modules.sourceforge.net/man/modulefile4.html all of the "See also" links are dead.

Victor.

Reported by: eijkhout

Would it be possible to fix init/perl.in to have a 1; at
the end of perl.in, so it can be easily used with require?

Reported by: woodd

    The Environment modules software defaults

MANPATH
to /usr/man. This is not the best choice for all
systems. It would be
nice to have the ability to chose the default either at
run time or, failing
that, at compile time.

    The run time option might involve looking at a

adminstrator
modified file containing the machine MANPATH for each
invocation of
modulecmd, and chosing a default if the file doesn't
exist.

    The compile time option might replace the

explicit string
"/usr/man" with a configure variable accessible to the
builder.

Reported by: yobbo

We use software that sets an env variable with :
seperated paths to know where to find things. Instead
of hard coded path we put
$var1:$var2:$var3:/usr/bin as an example because var1,
var2, var3
get defined by the tool when it starts.

in the module file we use

prepend-path TOOL_PATH {$var1:$var2:$var3}

This works fine when the module is loaded.
but when the module is unloaded $var1:$var2:$var3
are not removed from TOOL_PATH

I was able to fix this problem by adding one line to
the utility.c

added at line 2414 case '$':

2409 for( i=0, j=0; i<path_len && j<(len - 1); i++,
j++) {
2410
2411 switch(path) {
2412 case '.':
2413 case '+':
2414 case '$':
2415 newpath++ = '\'; / devalue '.'
and '+' **/
2416 j++;
2417 break;
2418 }

Could this fix be applied to future releases?

Thanks
MGH

Reported by: *anonymous

This patch removes the trailing ':' character from the MODULEPATH variable set by the init scripts. This was a problem because if a module matched a directory in the root of the filesytem '/', that directory would be searched when 'conflict module' was used in the modulefile.

This change also changes the sed|awk pipe to one awk() command. Thanks to Michael Sternberg for this idiom.

Reported by: mark_hamilton

For the tcl version of modules and when g_force is set
to 0, proc unload-path incorrectly removes variables
from the path. This occurs when multiple variables are
loaded/unloaded with a single command. set doit 0
should be inside the foreach loop to reset doit for
each variable.

An Example

module one:
append-path FOO var1:var2

module two:
append-path FOO var2:var3

After both modules are loaded:

FOO=var1:var2:var3
FOO_modshare=var1:1:var2:2:var3:1

After module unload one:

FOO=var3
FOO_modshare=var2:1:var3:1

But it should be:

FOO=var2:var3
FOO_modshare=var2:1:var3:1

Reported by: emastrom

Attempting a fairly complex setup, found that a
version name that's a substring of another version
name isn't allowed, due to a perhaps-overzealous loop
detection in cmdVersion.c/scan_versions(). Attached
patch is first stab at fix (scan_versions seemed to
be only area that's actually affected, but I'm not
too familiar with the modules code, so not sure)

One might ask why we wanted such a thing! The setup
attempted in which we encountered this follows:

We have a package, say "blah", it can be built for
different compilers and architectures, all of which
are reasonable choices with different tradeoffs for
our machine (linux x86_64 cluster), so different
users have different preferences. So, adopt a
comma-separated-components naming convention for
versioned modulefiles (commas appear to be a-okay
with modules and unix filesystems)

e.g.
""
blah/1.2.3,x86_64,gcc3
blah/1.2.3,x86_64,icc9
blah/1.2.3,x86,gcc3
blah/1.2.3,x86,icc9
""

But what if a user just wants to load e.g. the latest
gcc,x86 build?, say for putting in a long-lived build
script.

Easy: Make a module-version "x86,gcc3" pointing to
the latest, in modulerc. Now make appropriate
versions for all manner of combinations (writing a
routine to do it helps...), and a user can type:
"module load blah/x86" or
or
"module load blah/x86_64,gcc3"
"module load blah/1.2.3,icc9"
as appropriate.

But such a scheme only works if the same concrete
module file can have e.g. both "icc9" and
"1.2.3,icc9" versions pointing at it! Hence,
bug/patch.

Reported by: dgoldendias

3.2.3 doesn't compile on HPUX 10.20 using HP ANSI-C
compiler

Trying to compile, I get:
cc -DHAVE_CONFIG_H -I. -I. -I. -
I/pd/tcl8.4.1/include -I/usr/contrib/X11R6/include
+DAportable -Ae +O2 -D_POSIX_SOURCE -D_XOPEN_SOURCE -
D_XOPEN_SOURCE_EXTENDED -D_HPUX_SOURCE -c -o modulecmd-
ModuleCmd_Avail.o test -f 'ModuleCmd_Avail.c' || echo './'ModuleCmd_Avail.c
cc: "ModuleCmd_Avail.c", line 1039: error 1539: Cannot
do arithmetic with pointers to objects of unknown size.
cc: "ModuleCmd_Avail.c", line 1039: warning 563:
Argument #1 is not the correct type.
gmake[2]: *** [modulecmd-ModuleCmd_Avail.o] Error 1

I fixed this so: (one additional set of parenthesis)

diff -c ModuleCmd_Avail.c.orig ModuleCmd_Avail.c
*** ModuleCmd_Avail.c.orig Wed Jul 5 17:41:43
2006
--- ModuleCmd_Avail.c Wed Jul 5 17:26:29 2006

*** 1036,1042 ****
if( NULL == (list[(*beginning)++] = strdup
( ptr))) {
if( OK != ErrorLogger( ERR_ALLOC, LOC,
NULL)) {
while( i--)
! null_free((void ) list + (--
(beginning)));
return; / -------
EXIT (FAILURE) --------> **/
}
}
--- 1036,1042 ----
if( NULL == (list[(*beginning)++] = strdup
( ptr))) {
if( OK != ErrorLogger( ERR_ALLOC, LOC,
NULL)) {
while( i--)
! null_free((void ) (list + (--
(beginning))));
return; / -------
EXIT (FAILURE) --------> **/
}
}

This version then compiled and passed the tests

Reported by: *anonymous

We are getting a repeated error when we attempt to load more than two
modules at the same time. Sequential loads are not a problem.

Modules 3.2.5
RHEL4 and TCL 8.4

the error we get:

*** glibc detected *** free(): invalid pointer: 0x0000000000557db8 ***

sementation fault

Reported by: jaymcphee

Hello,

there is a Problem with the -specific initialization
script .../init/perl. There are two missing "ENV" in this
script:

6c6
< $ENV{MODULE_VERSION_STACK}="$ENV
{MODULE_VERSION}";

> $ENV{MODULE_VERSION_STACK}
="$MODULE_VERSION";
19c19
< $ENV{MODULEPATH} = sed 's/#.*$//' $ENV {MODULESHOME}/init/.modulespath | awk 'NF==1{printf ("%s:",$1)}'

> $ENV{MODULEPATH} = sed 's/#.*$//' ${MODULESHOME}/init/.modulespath | awk 'NF==1 {printf("%s:",$1)}'

Reported by: *anonymous

Using modules-3.1.6 with Tcl 8.3.3

Got an error using 'module use', which didn't appear on
commands like 'module add' and such. There were always
a few of these errors, looking like below

cmdPath.c(192):ERROR:102: Tcl command execution failed:
/app/modules /app/tcl/8.3.3/lib/tcl8.3
/app/tcl/8.3.3/lib ./lib

Only everything worked perfectly well, strangly. So I
went into the source to find the cause, after a bit of
digging trying to find the source of the terror I found
in the init.c file a Tcl_VarEval to add AUTOLOADPATH
value to auto_path. This was the source of the problem,
since the Tcl_VarEval was deprecated according to the
man pages. So I though to give it another work around
using a Tcl_SetVar, which in this case should give the
same result, well, in my case it atleast gave up on the
error messages.

The problem was that the Tcl_VarEval failed and gave
the TCL interpreter a failing result, this wasn't
cleard so later when other commands where executed and
checked for failure (in cmdPath.c for example) there
was one, only it was the old one from Tcl_VarEval,
giving the same error message at several places.

Now it works perfectly well.

Cheers,
Daniel

Reported by: heruffa

Here is the output of the make:

rome.kmb> make all
gcc -o modulecmd -L/usr/local/ActiveTcl/lib -
L/usr/openwin/lib -R/usr/openwin/lib -
R/usr/openwin/lib:/usr/local/ActiveTcl/lib -g
ModuleCmd_Avail.o ModuleCmd_Clear.o
ModuleCmd_Display.o ModuleCmd_Help.o ModuleCmd_Init.o
ModuleCmd_List.o ModuleCmd_Load.o ModuleCmd_Purge.o
ModuleCmd_Switch.o ModuleCmd_Update.o ModuleCmd_Use.o
ModuleCmd_Whatis.o cmdAlias.o cmdConflict.o
cmdIsLoaded.o cmdInfo.o cmdMisc.o cmdModule.o
cmdPath.o cmdSetenv.o cmdUname.o cmdXResource.o
cmdUlvl.o cmdLog.o cmdTrace.o cmdVersion.o
cmdVerbose.o cmdWhatis.o init.o locate_module.o
utility.o main.o error.o getopt.o version.o -ltcl8.3 -
lXmu -lXt -lX11 -lXext -ldl -lm
collect2: ld terminated with signal 11 [Segmentation
Fault]
make: *** [modulecmd] Error 1

Reported by: *anonymous

Building 3.2.7:

make[2]: Entering directory /builddir/build/BUILD/modules-3.2.7/init' sed -e "/@VERSIONING\@/d; \ s,@NOTVERSIONING\@,,g; \ s,@prefix\@,/usr/share/Modules,g; \ s,@bindir\@,/usr/share/Modules/bin,g; \ s,@VERSION\@,3.2.6,g; \ s,@BASEPREFIX\@,/usr/share,g;" < bash.in > bash make[2]: *** No rule to make target bash_completion', needed by `install-inits'. Stop.

Looks like init/bash_completion.in didn't make it into the tarball.

Reported by: opoplawski

CMake (www.cmake.org) is a build system. I've found it useful to have access to modules from within cmake scripts. This patch adds 'cmake' as a valid shell for modules and adds a cmake init script.
The patch is against 3.2.7.
Example usage (cmake file):

include(path/to/init/cmake)
module(load some-module)
module(use /path/to/more/modules)

Reported by: nwaisbrot

Valgrind on the C version reports overlapping strings in a strcmp, here's one way to fix it:

diff --git a/cmdPath.c b/cmdPath.c
index e88dcf7..9be6165 100644
--- a/cmdPath.c
+++ b/cmdPath.c
@@ -796,7 +796,7 @@ static int Remove_Path( Tcl_Interp *interp,
** We must be in SW_STATE3 or not in SW_STATE at all.
** Removing the marker should be just like removing any other path.
**/

•   strcpy( startp + start_offset, endp);
  

•   memmove( startp + start_offset, endp, strlen(endp)+1);   // May overlap
  
    /**
     **  Cache the set.  Clear the variable from the unset table just
  

Reported by: wsnyder2

Currently, the feature that enables the use of the
count of path elements is disabled. The feature is
controlled by g_force in modulecmd.tcl. Can this
feature be enabled by default or can a mechanism be
implemented to allow a user to turn this feature on/off
without modifying modulecmd.tcl.

g_force is used by the proc unload-path. The current
value of 1 forces all variables added to a path to be
removed, regardless of the number of times that
variable was added. This causes problems when multiple
modules append the same value to a path. See the
modules-interest list thread "Multiple Modules setting
the same env var" for more information.

Reported by: emastrom

Module purge produces error messages when run. This is because it unloads modules in the order they were loaded, packages should be unloaded as a stack to eliminate dependency errors. The attached patch addresses this problem.

Reported by: carriees

Just wanted to share the following with you. Note that after I do a "modules purge", the modules stay loaded. When I add or remove a random module, module purge suddenly works.

[root@sl5-mdv ~]# module load shared intel/cce intel/fce lam/intel/64 gotoblas
[root@sl5-mdv ~]# module list
Currently Loaded Modulefiles:

1. shared 4) lam/intel/64/7.1.3
2. intel/cce/9.1.049 5) gotoblas/prescott/64/1.11
3. intel/fce/9.1.045
   [root@sl5-mdv ~]# module purge
   [root@sl5-mdv ~]# module list
   Currently Loaded Modulefiles:
4. shared 4) lam/intel/64/7.1.3
5. intel/cce/9.1.049 5) gotoblas/prescott/64/1.11
6. intel/fce/9.1.045
   [root@sl5-mdv ~]# module unload gotoblas
   [root@sl5-mdv ~]# module purge
   [root@sl5-mdv ~]# module list
   No Modulefiles Currently Loaded.
   [root@sl5-mdv ~]# module load shared intel/cce intel/fce lam/intel/64 gotoblas
   [root@sl5-mdv ~]# module list
   Currently Loaded Modulefiles:
7. shared 4) lam/intel/64/7.1.3
8. intel/cce/9.1.049 5) gotoblas/prescott/64/1.11
9. intel/fce/9.1.045
   [root@sl5-mdv ~]# module purge
   [root@sl5-mdv ~]# module list
   Currently Loaded Modulefiles:
10. shared 4) lam/intel/64/7.1.3
11. intel/cce/9.1.049 5) gotoblas/prescott/64/1.11
12. intel/fce/9.1.045
    [root@sl5-mdv ~]# module unload lam
    [root@sl5-mdv ~]# module list
    Currently Loaded Modulefiles:
13. shared 3) intel/fce/9.1.045
14. intel/cce/9.1.049 4) gotoblas/prescott/64/1.11
    [root@sl5-mdv ~]# module purge
    [root@sl5-mdv ~]# module list
    No Modulefiles Currently Loaded.
    [root@sl5-mdv ~]# module load shared intel/cce intel/fce lam/intel/64 gotoblas
    [root@sl5-mdv ~]# module purge
    [root@sl5-mdv ~]# module list
    Currently Loaded Modulefiles:
15. shared 4) lam/intel/64/7.1.3
16. intel/cce/9.1.049 5) gotoblas/prescott/64/1.11
17. intel/fce/9.1.045
    [root@sl5-mdv ~]# module load pathscale
    [root@sl5-mdv ~]# module list
    Currently Loaded Modulefiles:
18. shared 4) lam/intel/64/7.1.3
19. intel/cce/9.1.049 5) gotoblas/prescott/64/1.11
20. intel/fce/9.1.045 6) pathscale/3.0
    [root@sl5-mdv ~]# module purge
    [root@sl5-mdv ~]# module list
    No Modulefiles Currently Loaded.
    [root@sl5-mdv ~]#

Reported by: *anonymous

Version 3.2.3

When I start modulecmd without arguments, the program
crashes:

$ modulecmd
init.c(294):ERROR:11: Usage is 'modulecmd shellname'
Segmentation fault

Due to utility.c:2994 (OutputExit):

if( !strcmp( shell_derelict, "csh")) {

Where shell_derelict is, of course, NULL.

Reported by: dennisvd