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>