Q: Compound conditions in ksh

Q: Compound conditions in ksh

Post by Guenther Steinmetz -289 » Fri, 22 Dec 1995 04:00:00



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?

Thanks for any answers.

+----------------------------------------------------------------------+
|  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

Post by Chet Ram » Fri, 22 Dec 1995 04:00:00




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

Post by Brendan O D » Sat, 23 Dec 1995 04:00:00






[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

 
 
 

1. ksh errexit compound commands help

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

2. Errors making most

3. What's 'side effects' of Ksh built-ins?

4. 24 bpp blues

5. Qs on ksh parameter expansion (BUG?)

6. SLIP server with Linux.

7. ksh evaluating conditions

8. who have experience use DOC to boot?

9. Condition checking "<=" and ">=" in ksh script

10. A Compound Makefile

11. Function as OLE compound document?

12. What's wrong with this compound comparison expression??

13. Ksh93 question: typeset and compound assignments