## Q: Compound conditions in ksh

### Q: Compound conditions in ksh

I have a question regarding compound conditions in ksh: Do you enclose the
total condition in parenthesis or not?

Example:
if (( keep_ofil == 0 )) && [[ ! -z \$ofil ]]; then
rm \$ofil
fi
or
if ( (( keep_ofil == 0 )) && [[ ! -z \$ofil ]] ); then
rm \$ofil
fi

It seems to work both ways. Is there any difference in how these two cases
are handled by ksh?

+----------------------------------------------------------------------+
|  Guenther Steinmetz           Mail:  Postfach 810247  81902 Muenchen |
|  Quality Consultant           Voice: (49) 89-9591-2892               |
|  Digital Equipment GmbH       Fax:   (49) 89-9591-2575               |
+----------------------------------------------------------------------+

### Q: Compound conditions in ksh

Quote:>I have a question regarding compound conditions in ksh: Do you enclose the
>total condition in parenthesis or not?

Not usually.

Quote:>Example:
>    if (( keep_ofil == 0 )) && [[ ! -z \$ofil ]]; then
>        rm \$ofil
>    fi
>or
>    if ( (( keep_ofil == 0 )) && [[ ! -z \$ofil ]] ); then
>        rm \$ofil
>    fi

>It seems to work both ways. Is there any difference in how these two cases
>are handled by ksh?

In the second case, the compound command (the pair of tests) is run
in a subshell.  In the first case, it is run by the same shell that's
running the rest of the script.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer

### Q: Compound conditions in ksh

[snip]
>>Example:
>>    if (( keep_ofil == 0 )) && [[ ! -z \$ofil ]]; then
>>        rm \$ofil
>>    fi
>>or
>>    if ( (( keep_ofil == 0 )) && [[ ! -z \$ofil ]] ); then
>>        rm \$ofil
>>    fi

>>It seems to work both ways. Is there any difference in how these two cases
>>are handled by ksh?

>In the second case, the compound command (the pair of tests) is run
>in a subshell.  In the first case, it is run by the same shell that's
>running the rest of the script.

Although this was true for Bourne shell (& bash?), no Korn shell I have
used actually forks a sub-shell for this case, from the manuals:

sh:   (list)  Execute list in a sub-shell.
ksh:  (list)  Execute list in a separate environment.

The effect is the same, ie. any changes to the environment are not
visible after the right paren, but ksh is more efficient (and stingy
with processes).

WRT the original poster's question, there is no functional difference
B/W the two case you gave, but you can use curly braces (or parens) to
group conditions.  Consider [a somewhat contrived example]:

if false && false || true
then
print executed
fi

if false && { false || true; }   # or if false && (false || true)
then
print not executed
fi

Regards,
--

Compusol Pty. Limited                   (NSW, Australia)  +61 2 809 0133

I am running Intergraph's CLIX 3.1 r.6.5.7 ( an AT&T system V release 3
derivative I believe) on an Intergraph workstation.

I am having unexpected behaviour with a ksh script as follows:

#
# This is a simple subshell command group which invokes the errexit function
#
(
set -e
trap "echo exit trap; exit 1" ERR
(exit 1)
echo \$?
exit 0
)

#
# The following test should be equivalent to a '||' OR list
#
if [[ \$? != 0 ]]
then
echo failed
fi

#
# In the following case, '||' OR list is used. I expected the result
# to be the same as the sequence above, but it isn't. For some reason,
# on my system the OR list interferes with the 'errexit' (-e) function,
# and the trap is never executed.
#
(
set -e
trap "echo exit trap; exit 1" ERR
(exit 1)
echo \$?
exit 0
) || echo failed

Intergraph says this works as designed. Their explanation is that the
set -e option failes in the latter case because the subshell command
grouping is a component of a larget compound command (the OR list).

I though the subshell command grouping '(compound-list)' was
functionally equivalent to running compound-list in a subshell, except
that the process number doesn't change, in which case whether it was
part of a larger compound command would be irrelevant.

Can anyone try this on other implementations and let me know what the
results are?

Is Intergraph wrong and this a bug, or have I misunderstood something?

Thanks for any help.

Ian Goodacre