#1. I want it my ENV file to act like the ".cshrc" file in csh --
to be read anytime a new, interactive shell starts.
So, I have my ENV variable set this way in .profile:
ENV='$HOME/.kshrc'; export ENV
The filename is in single-quotes. That way, when I run the 'su'
command to start a shell on another account, the ksh on *that* account
will read the .kshrc file for *that* account's $HOME. (If I'd used
double-quotes, the *same* .kshrc file would be read for *all* accounts.)
So now, each time I start a shell, it reads that account's $HOME/.kshrc.
Anybody see problems, or know another way to make this work?
#2. The next problem I have with ENV files -- if their name is stored
in the environment (export ENV) -- is that Korn shell script files
(shell programs) read them too. I have some stuff in my ENV file that
screws up shell scripts.
Here's how I fixed the problem. I put this at the start of my ENV file:
case "$-" in
*i*) ;; # IF SHELL IS INTERACTIVE, READ THIS FILE
*) return ;; # ELSE, EXIT AND DON'T READ IT
It works. For non-interactive shells, the ENV file isn't read --
and the rest of the shell program runs just fine, like I want.
The problem is, TFM doesn't seem to say whether that's legal. It says:
- If return is invoked while not in a function or a script,
then it is the same as an exit .
- exit n Causes the shell to exit with the exit status specified by n.
The first one says that return inside a script is not the same as exit,
but it doesn't say *how* it's different. (Is an 'ENV' file a "script?")
Anyhow, am I doing anything that I'll regret? :-)
--Jerry Peek; Syracuse University Academic Computing Services; Syracuse, NY
+1 315 443-3995
That's a Korn shell design botch. Apparently DGK thought that the C shell
behavior should be mimicked. Too bad he didn't first notice what a pain
it already was for C shell users. When Doug Kingston and I added a
similar feature to the BRL Bourne shell, we were more careful, and I think
ours works right. It does NOT get sourced for shell scripts (unless they
decide to source the file themselves, which would be exceedingly rare).
From "The Kornshell Command and Programming Language" by Morris I. Bolsky and
David G. Korn, Prentice-Hall, 1989, ISBN 0-13-516972-0, page 78:
# The subscript below evaluates to 0 when interactive.
This way ENV expands to null when the shell is not interactive. I use this and
it works perfectly.
I also highly recommend the book - it's a great reference with some really good
examples of the power of the Kornshell.
# Steve Vinoski # Apollo, a Subsidiary of HP # ARPA: vin...@apollo.com #
# (508)256-6600 x5904 # Chelmsford, MA 01824 # UUCP: ...!apollo!vinoski #
# "...no hardware designer should be allowed to produce any piece of hardware #
# until 3 software guys have signed off for it." -Andy Tanenbaum #
Doug Gwyn replies:
>That's a Korn shell design botch. Apparently DGK thought that the C shell
>behavior should be mimicked. Too bad he didn't first notice what a pain
>it already was for C shell users. When Doug Kingston and I added a
>similar feature to the BRL Bourne shell, we were more careful, and I think
>ours works right. It does NOT get sourced for shell scripts (unless they
>decide to source the file themselves, which would be exceedingly rare).
I think there might be an additional reason Korn did it that way: because
the Korn Shell does not provide exportable shell functions. Using ksh, the
only way to have your personal shell functions (which are assumed to be
defined in the $ENV file) available when executing a script is to source
the $ENV file for every ksh invocation. (The BRL Bourne Shell doesn't let
you export functions to a sub-shell either, so its users have the same
You could argue that shell scripts that want or need these functions should
source the necessary files themselves (and I would agree with you), but
maybe Korn thought otherwise when he put the feature into ksh.
(I can't resist a plug). In BASH, the Gnu Bourne-Again SHell, functions are
exportable. Version 1.03 was just released, grab it from prep.ai.mit.edu.
Chet Ramey (a bash contributor)
Chet Ramey "We are preparing to think about contemplating
Network Services Group, CWRU preliminary work on plans to develop a
ch...@cwjcc.INS.CWRU.Edu schedule for producing the 10th Edition of
the Unix Programmers Manual." -- Andrew Hume
As a security measure, I think it is ESSENTIAL that ordinary shell scripts
not import aliases, functions, IFS, PATH, or other things that could cause
unintended behavior. PATH is easy to fix in the script, and all ours do,
but the others are harder and should not be allowed to occur in the first
place. Recent BRL Bourne shells do not import IFS, and modulo a bug that's
now been fixed they've never tried to source the $ENV file for scripts.
The BRL shell sources the $ENV file for interactive shells (only). Most
of us keep our shell functions in a file ~/.funcs that the $ENV file
(typically named ~/.env) sources if it exists. I also keep my command-
line editing key bindings in a separately sourceable file ~/.shbind. If
some such convention were adopted sitewide, then shell scripts that felt
it appropriate could source the user's shell definition files. However,
I can't think of many non-interactive circumstances where that's appropriate.
>(I can't resist a plug). In BASH, the Gnu Bourne-Again SHell, functions are
>exportable. Version 1.03 was just released, grab it from prep.ai.mit.edu.
I considered doing that for the BRL shell, using the 9th Edition UNIX
syntax for the environment variables, but discovered that it caused
problems for existing (Bourne) shells and backed it out. Of course it
still would have been limited to interactive shells. The overhead of
sourcing $ENV as opposed to carrying the LARGE amount of extra environment
around with every process seems to be a good trade-off.
>The overhead of
>sourcing $ENV as opposed to carrying the LARGE amount of extra environment
>around with every process seems to be a good trade-off.
Is this still true if you have fork() with copy-on-write?