Subject: Re: CVS commit: basesrc/bin/ksh
To: Joerg Klemenz <joerg@gmx.net>
From: Greg A. Woods <woods@weird.com>
List: tech-userlevel
Date: 09/30/2002 13:38:37
[ On Monday, September 30, 2002 at 13:54:48 (+0000), Joerg Klemenz wrote: ]
> Subject: Re: CVS commit: basesrc/bin/ksh
>
> Greg A. Woods wrote:
> > 
> > $ENV _is_ the "real rc file" for ksh (and POSIX sh)!!!!
> 
> Thats the problem, as I see it

It can only be a problem if you fail to understand how to exploit it.

In fact $ENV is a feature with some rather deep design insight.  Perhaps
this section of P1003.2a/D8 will help explain better:

    ENV         This variable, when the shell is invoked, shall be
                subjected to parameter expansion (see 3.6.2) by the shell
                and the resulting value shall be used as a pathname of a
                file containing shell commands to execute in the current
                environment.  The file need not be executable.  If the
                expanded value of ENV is not an absolute pathname, the
                results are unspecified.  ENV shall be ignored if the
                user's real and effective user IDs or real and effective
                group IDs are different.  This standard specifies the
                effects of this variable only for systems supporting the
                User Portability Utilities Option.

along with these additional comments from the P1003.2a Rationale:

    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.

                The ENV value is interpreted in a manner similar to a dot
                script, in that the commands are executed in the current
                environment and the file needs to be readable, but not
                executable.  However, unlike dot scripts, no PATH
                searching is performed.  This is used as a guard against
                Trojan Horse security breaches.

> The problem is, as I see it, that ksh does not load any defaults when
> $ENV is not defined in .profile. But .profile is only loaded for
> interactive login shells.

This is a good thing.  See above.

> Makes a lot of sense to me

Executing ~/.cshrc for non-interactive shells by default is a design flaw.

If you really want to have a common initialisation script run when a
non-interactive ksh is started then all you need to do is ensure $ENV is
set appropriately for the shell instance(s) in question.  This is
trivial to arrange for specific instances of all the cases you've
mentioned already.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>