modules-interest

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

Re: Useful Features?

[J. P. <J....@Qu...>]

dpi said;
> Why sould one put the path-things in .cshrc? I thought, the value of
> PATH in a further shell is the same as in the login shell?

There are a number of situations where shells are not started
from a login shell and so they can't inherit the PATH. The most
common of these occurs when using remsh (rsh), where a correct path
on the remote machine may be essential. There might also be problems
in some X11 environments etc.

I believe that just about everyone recommends placing vital
environment variables in .(t)cshrc. The way I look at it is
that .login only performs things that are required once per login 
(like checking mail, launching processes etc.) but the rc file sets
up everything that is required for *every* invocation of that shell
(The rc file should not write to STDOUT however).
Likewise this is where the module calls should go too.

John P.

Environment variables in login/shell init [was: Useful Features?]

[Todd B. - N. <TBR...@RT...>]

>>>>> "John" == J Pelan <J....@Qu...> writes:

    John> dpi said;
    >> Why sould one put the path-things in .cshrc? I thought, the value of
    >> PATH in a further shell is the same as in the login shell?

    John> There are a number of situations where shells are not started
    John> from a login shell and so they can't inherit the PATH. The most
    John> common of these occurs when using remsh (rsh), where a correct path
    John> on the remote machine may be essential. There might also be problems
    John> in some X11 environments etc.

    John> I believe that just about everyone recommends placing vital
    John> environment variables in .(t)cshrc. The way I look at it is
    John> that .login only performs things that are required once per login
    John> (like checking mail, launching processes etc.) but the rc file sets
    John> up everything that is required for *every* invocation of that shell
    John> (The rc file should not write to STDOUT however).
    John> Likewise this is where the module calls should go too.

Guess I don't fit in with "just about everyone", because I don't
recommend this! In fact, I usually recommend NOT setting environmental
variables in the .kshrc/.cshrc/... files. After all, the interesting
thing about an environment variable is that it is inherited by child
processes. Often I have two xterms running two shells with different
environments at the same time; perhaps because I have two different
versions of vendor software going, or because I am working on
different projects that use environment variables to specify data
directories, etc. When I invoke ksh scripts I don't want them to reset
the PATH or other environment variables; I actually *want* different
environments to be inherited down different process trees. Likewise,
this is where module files should NOT go. I load my default modules in
my .(z)profile, then sometimes switch them to other modules in various
invokations of interactive shells.

I haven't had any problems with X; it just gets the environment active
at the time that I start xinit. But maybe some implementations are
different. I would be interested in the problems.

remsh that does not execute a login startup file is a problem, but I
need to solve it a different way because if I have a choice of
environments for software versions or something (or equivalently, a
choice of modules), I need a way to convey that choice to the remote
shell. So one possibility might be to have the remote command be a
script that has some arguments that set the environment/module inside
the script. Another is to write a generalized way to save the current
environment in a file, create the remote process, warp its environment
to match that of the file, and then execute the desired commands. This
is like creating a "virtual child" process on another machine, at
least with respect to the environments.

Anyway, there's my $0.02, which may not be worth much in the UK!

--
Todd Bridges - IBM PowerPC Embedded Processor Design
tbr...@ra...  919/543-4535 (office)
PO Box 12196, Dept. B52, Bldg 060/E125, RTP, NC 27709
jtb...@wo... (fun stuff)

Re: Useful Features?

[<dep...@i3...>]

Hi,

> 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.
Why sould one put the path-things in .cshrc? I thought, the value of
PATH in a further shell is the same as in the login shell?


> > 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.

In 'user-setup' there's something like this implemented with modules.
Just look at their module-file-examples.

dpi