Subject: Re: CVS commit: basesrc/bin/ksh
To: None <email@example.com>
From: Joerg Klemenz <firstname.lastname@example.org>
Date: 09/30/2002 13:54:48
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
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 <email@example.com>