jon@jonlab.UUCP (Jon H. LaBadie) (12/06/89)
I'm currently developing a ksh script that needs to know the name
of the "ENV" file read when ksh is exec'ed. However, it is not as
simple as reading the value of the ENV parameter. Some ksh users,
myself included, use a trick suggested by David Korn to avoid reading
the ENV file upon starting a non-interactive. This improves the
startup performance of ksh scripts considerably.
Now the problem is my new script will not be interactive, BUT needs
the interactive ENV value. How to get it? My solution so far is:
EnvFile=`ksh -ic 'eval echo "\"${ENV}\""' 2>/dev/null`
I.e. I start up another ksh, with the -i flag' and have it print its
ENV value. This works (except on one system it hangs for unknown
reasons) but I don't like starting one ksh for command substitution
(the `...`) and to start another just to get the ENV value.
I've worked out another way to accomplish the same result using my
own values for ENV etc., but am unsure as to how universal the
technique is. From my .profile:
export KSH_RC=${HOME}/.ksh_env # the real env file
export ENV='${KSH_RC[(_$-=1)+(_=0)-(_$-!=_${-%%*i*})]}'
My new technique in the shell script is:
eval real_env="${ENV%%[[]*}}"
I.e. Discard everything from the opening "[" in ENV's value, add a new
closing brace and reevaluate the remainder which is "${KSH_RC}".
Obviously, I'm making the assumption that all such ENV tricks use
array subscripts.
How universal is this assumption? Any ksh users employ tricks that
would defeat this scheme?
I hate to request mail responses, but my news feed has been down for
about 2 weeks and is expected to be down for an extended period. I
can be reached via:
...!princeton!jonlab!jon
...!bcr!jonlab!jon # for telco types
...!att!jonlab!jon # for those on AT&T systems
attmail!auxnj!jon # for ???
Thanks,
--
Jon LaBadie
{att, princeton, bcr}!jonlab!jon
{att, attmail, bcr}!auxnj!jon