Re: Useful Features?

[<re...@me...>]

See comments below...

> From: Ian Flanigan <fl...@cs...>
> 
> I'm new to the Modules system.  Until recently, I've been using a
> similar system developed at Washington University in St. Louis called,
> for lack of a better name, "the package system".
> 
> For one, the package system uses a special startup file (.pkgrc) to
> keep track of a user's default packages/modules.  The .pkgrc file is
> merely a list of packages/modules that should be loaded into every
> shell.  This is convenient since it's easy for a user to edit, it's
> easy to programatically add and delete modules, and it doesn't involve
> the shell's rc files at all.  This is good because it allows us to
> give all users standard shell rc files *that they can't change*.
> (We add a callout to a user startup file so that people can customize
> their environment *after* all the global stuff is set up.)

The problem is that users edit them.  In my user-setup[1] paper I
describe what happens when you encourage people to edit startup files:
confusion, rc-file viruses, and general mayhem.  Adding a callout
will not fix these problems.  The Modules approach is also susceptible
to this, but the difference is that a properly configured Modules 
environment (IMHO) should not require anyone to edit an rc file.  
Indeed, they shouldn't know an rc file exists.

Obviously gurus will hack, but one can never satisfy a guru can they :-)

With more modern UNIXes, one can get even more clever by supporting
all shells with /etc/profile or /etc/login scripts which are always
executed before the user's .profile or .cshrc file.  But there are
still a number of UNIXes that don't do this (read: SunOS 4 stinks,
SunOS 5 is better :-)

> Another difference is that the package system allows a user to force a
> package/module to add things at the front or at the end of all the
> paths.  This way users have more control over where things appear in
> their paths.

I don't see why Modules is any different.

I will agree that for C-shell users, life is difficult.  Especially in
Modules.  The reason is that each shell will source ~/.cshrc but only
login shells also source ~/.login.  Hence, one must put all path stuff
in the .cshrc file which is not a good thing.  For that reason alone I
recommend a Korn shell (or [patched-with-latest-security-patch] Bash)
which is much more friendly with the ~/.profile and $ENV file.

> The package system also has short descriptions in its listing of
> available packages.  
[stuff deleted]

Go for it.  There is no reason why one couldn't have short help,
medium help, long help or whatever.  Remember, Modules is extensible,
though I don't yet agree that you need to extend Modules to add this
feature.  Just write clever modulefiles.

> I'd like to know if people would find these features useful.  Because
> of our current situation, it's necessary to implement some of these
> features before we migrate to the Module system anyway.

Don't forget that Modules is extremely flexible.  In fact, I'd bet that
you could write a modulefile to call your package scripts which in turn
call modules... :-)
 -- richard