ENV file in ksh: is this smart? legal?

[Doug Gwyn]

In article <526 at cwjcc.CWRU.Edu> chet at kiwi.INS.CWRU.Edu (Chet Ramey) writes:
>I think there might be an additional reason Korn did it that way: because
>the Korn Shell does not provide exportable shell functions.  Using ksh, the
>only way to have your personal shell functions (which are assumed to be
>defined in the $ENV file) available when executing a script is to source
>the $ENV file for every ksh invocation.  (The BRL Bourne Shell doesn't let
>you export functions to a sub-shell either, so its users have the same
>problem.)
>You could argue that shell scripts that want or need these functions should
>source the necessary files themselves (and I would agree with you), but
>maybe Korn thought otherwise when he put the feature into ksh. 

As a security measure, I think it is ESSENTIAL that ordinary shell scripts
not import aliases, functions, IFS, PATH, or other things that could cause
unintended behavior.  PATH is easy to fix in the script, and all ours do,
but the others are harder and should not be allowed to occur in the first
place.  Recent BRL Bourne shells do not import IFS, and modulo a bug that's
now been fixed they've never tried to source the $ENV file for scripts.
The BRL shell sources the $ENV file for interactive shells (only).  Most
of us keep our shell functions in a file ~/.funcs that the $ENV file
(typically named ~/.env) sources if it exists.  I also keep my command-
line editing key bindings in a separately sourceable file ~/.shbind.  If
some such convention were adopted sitewide, then shell scripts that felt
it appropriate could source the user's shell definition files.  However,
I can't think of many non-interactive circumstances where that's appropriate.

>(I can't resist a plug).  In BASH, the Gnu Bourne-Again SHell, functions are
>exportable.  Version 1.03 was just released, grab it from prep.ai.mit.edu.

I considered doing that for the BRL shell, using the 9th Edition UNIX
syntax for the environment variables, but discovered that it caused
problems for existing (Bourne) shells and backed it out.  Of course it
still would have been limited to interactive shells.  The overhead of
sourcing $ENV as opposed to carrying the LARGE amount of extra environment
around with every process seems to be a good trade-off.