Correct usage of .kshrc vs. .profile debate
Christopher D. Morgan
At our site, we have the root accounts set to use the Korn-shell as it's
primary shell. We also have root's /.profile set up to define ENV to be
$HOME/.kshrc of the user who su's to the root account. The main reason
for this is because each of the 10 or so systems administrators have
their own preferences for prompt settings etc.
Although all the system and application start/stop scripts in
/etc/init.d are Bourne shell (with the #!/bin/sh directive on the first
line), some of them call, in turn, other scripts that are Korn shell
(with the #!/bin/ksh directive on the first line). Some of these Korn
shell scripts, in turn, call reference java programs [the reference java
executable is actually a wrapper script that invokes the java executable
after performing some of its own environment settings].
Ok - with me so far ... here's the problem. Some of the systems
administrators are hard coding (not appending) variable definitions such
as LD_LIBRARY_PATH in their $HOME/.kshrc files. Why is this significant?
Well, if that sys admin su's to root, root then defines $ENV to be his
$HOME/.kshrc file which is then executed/sourced for every
sub-shell [ksh] from that point on. When that sys amdin then tries to
run one of the start/stop scripts in /etc/init.d, the following happens:
- The script in /etc/init.d is executed
- This script executes within a bourne shell
- The /etc/init.d calls another ksh script
- A korn shell sub-shell is invoked
- The sys admin's $HOME/.kshrc is executed/sourced
- As per the user's $HOME/.kshrc, LD_LIBRARY_PATH is overwritten and set
to some value
- The ksh script then proceeds to re-set LD_LIBRARY_PATH to what the
application requires (one of the first things that it does)
- The ksh script runs java (thus launching another sub-shell)
- The sys admin's $HOME/.kshrc is invoked again
- LD_LIBRARY_PATH is overwritten again
- The application fails because it does not have the correct
LD_LIBRARY_PATH setting and cannot find the required shared objects
Although not complete, this is the jist of the the goings on in this
situation.
We have a difference of opinion regarding the best way to resolve this
problem. Without losing my objectivity, I'll simply list the possible
solutions (that I can think of):
1. Stop using ksh for root's login shell
2. Stop writing Korn shell scripts (as these make use of $ENV)
3. Stop using user's $HOME/.kshrc for $ENV in the root account
4. Stop defining variables such as LD_LIBRARY_PATH in user's
$HOME/.kshrc (use $HOME/.profile instead)
5. Stop hard-coding variables such as LD_LIBRARY_PATH in user's
$HOME/.kshrc (append instead)
6. Use unset ENV in start/stop scripts in /etc/init.d
I think I have covered all possibilities (if anyone can think of some
more, please let me know).
O.k., which of the above solutions, if any, would be preffered and for
what reason(s).
Best regards,
Chris Morgan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Mr. Scott
>
> We have a difference of opinion regarding the best way to resolve this
> problem. Without losing my objectivity, I'll simply list the possible
> solutions (that I can think of):
>
> 1. Stop using ksh for root's login shell
> 2. Stop writing Korn shell scripts (as these make use of $ENV)
> 3. Stop using user's $HOME/.kshrc for $ENV in the root account
> 4. Stop defining variables such as LD_LIBRARY_PATH in user's
> $HOME/.kshrc (use $HOME/.profile instead)
> 5. Stop hard-coding variables such as LD_LIBRARY_PATH in user's
> $HOME/.kshrc (append instead)
> 6. Use unset ENV in start/stop scripts in /etc/init.d
>
> I think I have covered all possibilities (if anyone can think of some
> more, please let me know).
>
> O.k., which of the above solutions, if any, would be preffered and for
> what reason(s).
4&5, with a few modifications.
First, LD_LIBRARY_PATH, being an extremely important system level
variable should NOT be reset, and minimally tampered with. It should
be set in /etc/environment (that is on AIX) or /etc/profile (for those
who lack /etc/environment). After that point, the only tampering with
this variable should be to TEMPORARILY APPEND something to the
beginning or end. I would avoid at all costs playing with this
variable at all in any personal .kshrc or .profile files unless
absolutely necessary. Optimally it should be set in the beginning so
that it works for 99% of existing users and apps.
Donn Cave
...
| I think I have covered all possibilities (if anyone can think of some
| more, please let me know).
ENVFILE=$HOME/.kshrc
export ENVFILE
ENV='${ENVFILE[(_=1)+(_$-=0)-_${-%%*i*}]}'
export ENV
It's a fairly widely used trick, I didn't invent it and barely
understand it myself. ENV is .kshrc only when the shell is invoked
in an interactive context, and empty for a script, thanks to the
array indexing based on the value of $-.
Donn Cave, University Computing Services, University of Washington
do...@u.washington.edu
brian hiles
> Christopher D. Morgan <christop...@my-deja.com> writes:
> ...
> ENVFILE=$HOME/.kshrc
> export ENVFILE
> ENV='${ENVFILE[(_=1)+(_$-=0)-_${-%%*i*}]}'
> export ENV
Just the smallest quibble on a sublime solution....
ENVFILE=~/.kshrc export ENVFILE ENV='${ENVFILE[(_=1)+(_$-=0)-_${-%%*i*}]}'
How the above technique works (as first appearing in Bolsky and
Korn's "The Kornshell Command and Programming Language") is (keeping
the parenthetical grouping for clarity and adding implicit variable
dereference signs...)
Interactively, the expression (_=1)+(_$-=0)-_${-%%*i*} as a
side-effect sets the variables $_ to 1 and _ism to 0. This evaluates
to (0)+(1)-$_ = 0+1-1 = 0. ENVFILE[0] is the previously defined
value "$HOME/.kshrc".
Non-interactively, the expression (_=1)+(_$-=0)-_${-%%*i*} as a
side-effect sets the variables $_ to 1 and _h to 0. This evaluates
to (0)+(1)-$_h = 0+1-0 = 1. ENVFILE[1] is the null value, as this
array element has never been defined.
P.S. I read somewhere an analysis of a condition (and fix) where the
above code will fail. I cannot remember it off the top of my head.
P.P.S. ksh93 doesn't source the $ENV file for non-interactive files
and thus this problem does not exist. However, the above technique
will not break programs running in this shell.
-Brian
Dan Mercer
brian hiles <b...@rainey.blueneptune.com> writes:
> Donn Cave <do...@u.washington.edu> wrote:
>> Christopher D. Morgan <christop...@my-deja.com> writes:
>> ...
>
>> ENVFILE=$HOME/.kshrc
>> export ENVFILE
>> ENV='${ENVFILE[(_=1)+(_$-=0)-_${-%%*i*}]}'
>> export ENV
>
> Just the smallest quibble on a sublime solution....
>
> ENVFILE=~/.kshrc export ENVFILE ENV='${ENVFILE[(_=1)+(_$-=0)-_${-%%*i*}]}'
>
> How the above technique works (as first appearing in Bolsky and
> Korn's "The Kornshell Command and Programming Language") is (keeping
> the parenthetical grouping for clarity and adding implicit variable
> dereference signs...)
>
> Interactively, the expression (_=1)+(_$-=0)-_${-%%*i*} as a
> side-effect sets the variables $_ to 1 and _ism to 0. This evaluates
> to (0)+(1)-$_ = 0+1-1 = 0. ENVFILE[0] is the previously defined
> value "$HOME/.kshrc".
>
> Non-interactively, the expression (_=1)+(_$-=0)-_${-%%*i*} as a
> side-effect sets the variables $_ to 1 and _h to 0. This evaluates
> to (0)+(1)-$_h = 0+1-0 = 1. ENVFILE[1] is the null value, as this
> array element has never been defined.
>
> P.S. I read somewhere an analysis of a condition (and fix) where the
> above code will fail. I cannot remember it off the top of my head.
This is the fix. The original, buggy version was:
export ENV='${ENVFILE[(_$-=0)+(_=1)-_${-%%*i*}]}'
\ /
\ /
\ /
\/
/\
/ \
/ \
/ \
export ENV='${ENVFILE[(_=1)+(_$-=0)-_${-%%*i*}]}'
The expressions are just swapped.
--
Dan Mercer
dame...@uswest.net
>
> P.P.S. ksh93 doesn't source the $ENV file for non-interactive files
> and thus this problem does not exist. However, the above technique
> will not break programs running in this shell.
>
> -Brian
Opinions expressed herein are my own and may not represent those of my employer.