[ On Wednesday, October 2, 2002 at 23:50:15 (+0000), Joerg Klemenz wrote: ]
> Subject: Re: CVS commit: basesrc/bin/ksh
>
> Greg A. Woods wrote:
> > Your proposal doesn't fix the problem then, or indeed really help in
> > any useful way.  $ENV already does what you want.
> 
> My suggestion was to load kshenv for all shells, (interactive and
> nin-interactive), kprofile for login and kshrc for interactive shells
> (in that order).

Then you're changing your story half way through.  In the part of your
own post that you omitted from above you first said:

  [ On Tuesday, October 1, 2002 at 17:02:34 (+0000), Joerg Klemenz wrote: ]
  > Subject: Re: CVS commit: basesrc/bin/ksh
  >
  > Just make sure not to duplicate csh's design flaws and *not* load
  > kshrc for non-interactive shells (see other mail).

You can't have it both ways.

Csh's design flaw is that it loads /etc/csh.cshrc and ~/.cshrc for all
shells, and also first loads /etc/csh.login, ~/.login for interactive
shells.

Besides there is no such thing as any of "kshenv" "kshprofile" or
"kshrc".

For ksh and for all POSIX compatible shells there is /etc/profile and
~/.profile, which are loaded for interactive shells, and $ENV, which is
loaded whenever it is set in the environment of the shell.  Users can
still screw themselves by relying unconditionally on things found in
$ENV if they mis-use it.

> That would remove the need for any if's and case's in the login
> scripts, thereby making them easier to use and understand and more
> powerfull at the same time.

No, it wouldn't really, and it would just create an incompatible ugly
mess of a hack.

You already have all the flexibility you could possibly need and then
some.  Use it properly and you should be happy!  :-)

If you use the trick Korn originally suggested almost a decade ago, and
which I showed in a previous post and which I use in my own ~/.* files,
then you can have the decision of what $ENV file to load made
automatically based on whether the shell is interactive or not and thus
keep the content of your "interactive only" and "non-interactive" $ENV
files completely separate and completely free of the decision logic you
seem to so dread.  However be warned that if you do this you'll still
hopefully want to factor common things together into yet a third script.

Besides the whole point here (of avoiding csh design flaws) is to make
it very hard to accidentally modify the standard behaviour of a
non-interactive shell (or worse to have a user become reliant on some
non-standard quirk courtesy of a startup script).  You really do not
want to customize non-interactive shells by any even minimally
non-obvious mechanism.  Shell scripts, i.e. the things non-interactive
shells execute, should always be written only for standard environments
-- they should be be independent of any given user's login environment.
If you need to customize the environment or behaviour of a given script
then there much "safer" (portable, self-obvious and self-documenting)
ways do so.


> The login.conf file that you suggested is nice but very limited

It's not limited in any of the ways you claimed you wanted support for
-- indeed it's far more flexible than what is really needed to do what
you said you wanted to do.

> and I
> have no idea how portable that is (man page says it appeared in 1.5?)

RTFM and you'll know:

  HISTORY
     The login.conf configuration file appeared in NetBSD 1.5.


You seem want portability on one hand and non-portable hacks on another.

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