golder@nwnexus.WA.COM (Warren Jones) (10/04/90)
When writing a C shell script, you can start off with:
#! /bin/csh -f
... where the "-f" flag insures that the user's $HOME/.cshrc file
is not read. Efficiency is a secondary consideration here. More
important is making sure that the shell environment is predictable,
and that you don't unwittingly use an alias that was defined in .cshrc.
Does anyone know a way to avoid reading the user's $ENV file in
Korn shell scripts? I'm puzzled that a shell with so many features
apparently neglects this question.
Of course, you can always make the behavior of a script predictable
by writing all commands as fully qualified pathnames (e.g. "/bin/sed",
rather than just "sed"). But:
1. This is tiresome to write and makes scripts hard to read.
2. Who wants to have to remember which commands are in /bin,
which are in /usr/bin, and which are in /usr/ucb ? (Do
you have some other directories on your system ?)
3. I suspect that the distribution of commands among these
directories is not portable between various flavors of **ix.
Suggestions?
A related question: When working on an HP-UX system a while back,
I remember seeing in one of the manuals a trick for defining ENV
so that the variable expands to the desired file name for interactive
shells, but to a null string if the shell is not interactive.
NOTE: this is a different question, and does involve efficiency
(though I'm sure not in any critical way). After all, you don't
need to read the ENV file when the shell is simply being used
to glob some file names for an editor. The trick involved checking
the "$-" flags variable for the presence of the letter "i"
(indicating an interactive shell). I remember marveling at the
time how wonderfully obscure and arcane it was, but I can't quite
seem to reproduce it. Can anyone out there provide the answer?
--
----------------------------------------------------------------
Warren Jones <golder@nwnexus.wa.com> Golder Associates Inc.
(uucp: uunet!nwnexus!golder) 4104 148th Avenue NE
(206) 883-0777 Redmond, WA 98052, USApim@cti-software.nl (Pim Zandbergen) (10/05/90)
golder@nwnexus.WA.COM (Warren Jones) writes: >A related question: When working on an HP-UX system a while back, >I remember seeing in one of the manuals a trick for defining ENV >so that the variable expands to the desired file name for interactive >shells, but to a null string if the shell is not interactive. >NOTE: this is a different question, and does involve efficiency >(though I'm sure not in any critical way). After all, you don't >need to read the ENV file when the shell is simply being used >to glob some file names for an editor. The trick involved checking >the "$-" flags variable for the presence of the letter "i" >(indicating an interactive shell). I remember marveling at the >time how wonderfully obscure and arcane it was, but I can't quite >seem to reproduce it. Can anyone out there provide the answer? [[ ${-} = *i* ]] || ENV= -- Pim Zandbergen domain : pim@cti-software.nl CTI Software BV uucp : uunet!mcsun!hp4nl!ctisbv!pim Laan Copes van Cattenburch 70 phone : +31 70 3542302 2585 GD The Hague, The Netherlands fax : +31 70 3512837
jrh@mustang.dell.com (James Howard) (10/05/90)
In article <392@nwnexus.WA.COM>, golder@nwnexus.WA.COM (Warren Jones) writes: > > A related question: When working on an HP-UX system a while back, > I remember seeing in one of the manuals a trick for defining ENV > so that the variable expands to the desired file name for interactive > shells, but to a null string if the shell is not interactive. > > NOTE: this is a different question, and does involve efficiency > (though I'm sure not in any critical way). After all, you don't > need to read the ENV file when the shell is simply being used > to glob some file names for an editor. The trick involved checking > the "$-" flags variable for the presence of the letter "i" > (indicating an interactive shell). I remember marveling at the > time how wonderfully obscure and arcane it was, but I can't quite > seem to reproduce it. Can anyone out there provide the answer? > export FILE=$HOME/.kshrc # Define the ENV variable only when interactive. # If $ENV is defined, it is the name of the file which # contains further commands which customize the ksh environment. # If ksh isn't running interactively, there's no need to # run these commands. ENV='${FILE[(_$-=0)+(_=1)-_${-%%*i*}]}' This is pretty much straight out of the Korn book.. James Howard Dell Computer Corp. !'s:uunet!dell!mustang!jrh (512) 343-3480 9505 Arboretum Blvd @'s:jrh@mustang.dell.com Austin, TX 78759-7299
gt0178a@prism.gatech.EDU (Jim Burns) (10/05/90)
in article <392@nwnexus.WA.COM>, golder@nwnexus.WA.COM (Warren Jones) says: > Does anyone know a way to avoid reading the user's $ENV file in > Korn shell scripts? I usually just redefine $ENV in a wrapper. E.g. this script (t1): #!/local/bin/ksh -x functions alias yields different results when executed by itself than by executing: unset ENV t1 -- BURNS,JIM Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a Internet: gt0178a@prism.gatech.edu