Greg A. Woods wrote:
> [ On Sunday, September 29, 2002 at 17:40:33 (+0000), Joerg Klemenz wrote: ]
> > Subject: Re: CVS commit: basesrc/bin/ksh
> >
> > All of this hacks are only needed because of ksh's lack of a "real" rc
> > file.
> 
> $ENV _is_ the "real rc file" for ksh (and POSIX sh)!!!!

Thats the problem, as I see it

> > To make things even worse, there's no way that I know of to load
> > defaults for non-interactive non-logged-in shells.
> 
> You really should look at the complete working files I define.  It is
> not difficult at all to detect the difference between interactive and
> non-interactive shells from within the $ENV script.  The nifty trick I
> use for ksh simply assumes one doesn't need any $ENV script for
> non-interactive shells, but obviously there's more than one way to do
> these thigns.

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.

If you log in w/ csh and then run "ksh" it won't load anything, right?

If you login w/ ksh and run "csh" it executes /etc/csh.cshrc and ~/.cshrc.
That makes it very easy for the user: No need for workarounds and tons
of "if [..", just put everything in .cshrc

Makes a lot of sense to me

> > The retarded $ENV
> > construct assumes that the user is logged in when he starts a
> > non-interactive shell.
> 
> That's pure B.S.  If you can't start a non-interactive shell with preset
> environment variables then you should fix whatever facility you're using
> to start such shells because it is broken by definition.

How can I define a site wide environment for a ksh (or sh) schript
started from cron or rexec (other that manually including ENV in every
single crontab)?

With csh or zsh it's trivial: Just use /etc/csh.cshrc or /etc/zshenv

With sh or ksh it's impossible, right? I'm willing to learn.


-- 
joerg klemenz <joerg@gmx.net>