Shell Programming and Scripting

I am not a fan of && for series of actions, when this reads so much better and does not make for wacko indentation:

Code:

if step-1-exec+failure-predicate
then
 error-1-exit-or-return
fi

if step-2-exec+failure-predicate
then
 error-2-exit-or-return
fi
 .
 .
 .
 .

It gives you the opportunity to tell how far it ran, too.

Hi Kristinu,

You need to put doubles quotes around the variables on the left if you use single brackets...

Code:

 if [ "$drwtag" != "" ] && [ "$smptag" = "" ] ; then   # drw tag detected

Code:

elif [ "$drwtag" = "" ] && [ "$smptag" != "" ] ; then  # smp tag detected

S.

Yes in general unless you are exploding a list, $xxx s/b "$xxx" so embedded blanks or total blankness does not invalidate what you say. I even use quotes on constants, both for a sort of parity, to tell the reader it is a constant not a variable, command or other meta-word of some sort:

Code:

if [ "$xxx" = "true" ]
 then
  echo "Variable '$xxx' is 'true'!"
 fi

BTW, any time I find myself wanting to say 'elif' anywhere, I go to 'case' not 'if'. The case operator has a nice, clear structure showing the precedence of tests and the logical 1 of all cases being addressed in the design. It provides nice opportunities to hang comments, too.

In this case, 'case' also allows you to test the $f variable without fork, exec, pipe, print or awk. Also, the if [[]] has both kinds of pattern matching native in the shell.

Either 'case', or as I suggested above, a sequence of if's that, if true, terminate the flow with exit or return. My personal term for that sort of tree collapse is 'cut them off at the pass' (prevent complexity by early pruning of odd cases like error). Putting such in some sort of script or function ensures you can leave early, as soon as you have an answer, however negative or unlikely in real life, and then proceed to the finer points of your functionality free of those worries.

in post 25 already i mean "double" and 'single quotes' not differ for expand ere expression..for everybody understand in this issue in ksh
and in my post #23 is related ksh93 (before my fault i mean just ksh93) and unfortunately in ksh93 we cant this expression