Greg A. Woods wrote:
> [..]
> ENV This can be used to set aliases and other items local to the
> invocation of a shell.  The file referred to by ENV differs from
> $HOME/.profile in that .profile is typically executed at session
> startup, whereas the ENV file is executed at the beginning of each
> shell invocation.
> [..]
> Executing ~/.cshrc for non-interactive shells by default is a design
> flaw.

That's true. csh was a bad example. But ksh will also execute ENV for
non interactive shells if you call a script from a login shell if I'm
not mistaken. I would consider that an incarnation of the exact same
"design flaw".

You are right when you say it's better not to have an environment than
to have the interactive environment in your scripts. I don't actually
use csh for programming, so I wasn't aware of the implications of its
startup sequence.


An example: If you define "alias ls=ls -1F" in .cshrc or ENV that will
obviously trash your scripts.

If you move the definition to .profile (or .login) your scripts will
be save, but if the user starts a new shell, with xterm& for example,
the new shell will not have any aliases.


What [c|k]sh really needs, imho, is a third startup file that "frees"
the existing two ones for interactive use *only*.



	jörg