eravin@panix.uucp (Ed Ravin) (03/26/91)
I dragged my ksh environment over from my Sun workstation, and one
of the things I routinely turn on is 'set -u", so that shell variables
will cause an error if referenced before being declared (assigned). I
consider this good programming practice and protection against spelling
errors, but it caused the "/usr/lpp/bin/xinit" script to break because it
checks for the variable XSTATION without declaring it first or using suitable
defaulting (e.g. ${foo:-} or whatnot).
Should I make this burning issue my first call to Defect Support? Will they
even understand what I'm talking about? I suppose I could ask my SE but he
keeps saying things like "Boy, this AIX stuff is totally different from
everything else I know..."
----------------------------------------------------------------------------
Ed Ravin |
cmcl2!panix!eravin | pardon our appearance -- .signature under construction
philabs!trintex!elr |
--
----------------------------------------------------------------------------
Ed Ravin |
cmcl2!panix!eravin | pardon our appearance -- .signature under construction
philabs!trintex!elr |prener@arnor.UUCP (Dan Prener) (03/28/91)
If all uses of undefined shell variables are to be considered errors,
then it becomes very difficult to get first-time switches and to
keep other state. How, for example does shell script s1 tell whether
shell script s2 has been executed? Isn't this usually done by testing
some shell variable that will have been set by s2, or left unset if
s2 has not been executed?
--
Dan Prener (prener @ watson.ibm.com)eravin@panix.uucp (Ed Ravin) (03/28/91)
In article <mumble@arnor.uucp> prener@prener.watson.ibm.com (Dan Prener) writes: >If all uses of undefined shell variables are to be considered errors, >then it becomes very difficult to get first-time switches and to >keep other state. It's not at all difficult. The first time you reference any shell variable, you can specify a value to be used instead if the variable is not set or a value to assign it to if the variable is not set. For example: echo $FOO ${FOO} # normal references to a variable. Note that # the { } characters to delimit the variable name are optional. echo ${FOO:-default} # here, the word "default" will be used instead of # the FOO variable if FOO is not set. echo ${FOO:=intial_value} # If FOO is not set, it will be created # and assigned the value "initial_value" The nice thing about doing this is that you never get surprised -- for example, it's easy to do something like: myvalue="Isn't today a lovely day?" if [ $myvaleu = "No it isn't" ] then echo blah blah fi With set -u on, I would get an error message at the reference to "myvaleu", letting me know that I had goofed. The only hassle is that when you reference system variables like $@ and $*, you have to allow for the possibility that your script was called without parameters, and reference them instead with ${@:-} and ${*:-}. These constructions work in both ksh and Bourne shell. -- ---------------------------------------------------------------------------- Ed Ravin | Even if I could think of a profound, witty, insightful cmcl2!panix!eravin | quote to put here noone would bother reading it. philabs!trintex!elr |
bob@ibmpa.awdpa.ibm.com (Bob Andrews) (03/29/91)
In article <1991Mar28.153242.8791@panix.uucp>, eravin@panix.uucp (Ed Ravin) writes: |> In article <mumble@arnor.uucp> prener@prener.watson.ibm.com (Dan Prener) writes: |> >If all uses of undefined shell variables are to be considered errors, |> >then it becomes very difficult to get first-time switches and to |> >keep other state. |> |> It's not at all difficult. The first time you reference any shell variable, |> you can specify a value to be used instead if the variable is not set or a |> value to assign it to if the variable is not set. For example: |> You might also try changing the first line of the xinit script to: #! /bin/ksh -p I haven't tried this, so it may introduce other errors, but it should prevent the ksh from looking at your .profile, etc. files... -- --- Bob Andrews UNIX: bob@ibmpa.awdpa.ibm.com VNET: BANDREWS at AUSTIN (if you must)
eravin@panix.uucp (Ed Ravin) (03/30/91)
In article <mumble@ibmpa.awdpa.ibm.com> bob@ibmpa.awdpa.ibm.com (Bob Andrews) writes: >You might also try changing the first line of the xinit script to: > >#! /bin/ksh -p > >I haven't tried this, so it may introduce other errors, but it should prevent >the ksh from looking at your .profile, etc. files... Hmmm. This is the first system I've used that uses ksh as its default shell, so the system scripts are picking up my .kshrc. Considering the level of customization possible in ksh, and considering what some people do to their environments, it's probably wise for all system scripts to insist upon using only inheriting environment variables and not shell aliases or option settings. Since my last posting, I've discovered the "info" script also likes to reference uninitialized variables. Then again, the Info Explorer interface from an ASCII terminal is so dismal that I'm not sure I care... -- ---------------------------------------------------------------------------- Ed Ravin | Even if I could think of a profound, witty, insightful cmcl2!panix!eravin | quote to put here noone would bother reading it. philabs!trintex!elr |