[comp.sys.apollo] shell scripts, boolean variables, and eon

hanks-steven@YALE.ARPA (Steven Hanks) (03/25/88)

executing the following shell script produces weird 
results:

     #!/com/sh
     
     eon
     
     truevar :=  true
     falsevar := false
     
     if ^truevar      then args "yes" else args "no" endif
     if not ^truevar  then args "yes" else args "no" endif
     if ^falsevar     then args "yes" else args "no" endif
     if not ^falsevar then args "yes" else args "no" endif
  
     args ""

     if ((^truevar))      then args "yes" else args "no" endif
     if ((not ^truevar))  then args "yes" else args "no" endif
     if ((^falsevar))     then args "yes" else args "no" endif
     if ((not ^falsevar)) then args "yes" else args "no" endif
     
                        ||
                        VV


     yes
     no
     yes        <---   site of weirdness
     no         <---   site of weirdness

     yes
     no
     no
     yes

it looks to me like eon isn't working correctly.  though 
taking it out generates the expected "name not found" 
error message.   or maybe i'm missing something........
any ideas?

steve.

    hanks@cs.yale.edu         ....!decvax!yale!hanks
-------

nazgul@apollo.uucp (Kee Hinckley) (04/01/88)

In article <8803241941.AA09455@ELI.CS.YALE.EDU> hanks-steven@YALE.ARPA (Steven Hanks) writes:
> executing the following shell script produces weird 
> results:
> 
>      #!/com/sh
>      
>      eon
>      
>      truevar :=  true
>      falsevar := false
>      
>      if ^truevar      then args "yes" else args "no" endif
>      if not ^truevar  then args "yes" else args "no" endif
>      if ^falsevar     then args "yes" else args "no" endif
>      if not ^falsevar then args "yes" else args "no" endif
>   

That's a common shell problem (one of these days I should post a summary
of common problems).

There are two "not"s.  One negates commands, the other negates expressions.
Boolean values only make sense inside of expressions.  The case above would
in fact work fine if you happened to have executable files called "true" and
"false" in your search path, since in the context of a command the variables
are converted to strings, but anyway...

What you want to say is:

      if (( ^truevar ))      then args "yes" else args "no" endif
      if (( not ^truevar  )) then args "yes" else args "no" endif
      if (( ^falsevar ))     then args "yes" else args "no" endif
      if (( not ^falsevar )) then args "yes" else args "no" endif

I'm sorry about the (( )) syntax (which is necessary for all expressions
except the special case of assignments (e.g.  (( a := 1 )) isn't necessary)).
We needed some way to differentiate between expressions and commands (the
shell didn't have variables or any expression capability until SR8) without
breaking any old scripts and "(( ))" looked pretty safe, albeit awkward.

BTW, the necessity to use "eon" to turn on variable evaluation (unless you
feel like putting all your variables in double parenthesis) came about as
a last minute addition for much the same reason.  It turned out that people
were constructing Pascal code in shell here-documents
    catf <<!
        foo : ^char;
    ...
and of course it broke if variable evaluation was turned on.  Sigh.

Enough historical oddities for now.
                                                    -nazgul

-- 
### {mit-erl,yale,uw-beaver}!apollo!nazgul ###   (Apple ][e ProLine BBS)    ###
###      apollo!nazgul@eddie.mit.edu       ###    nazgul@pro-angmar.uucp    ###
###           nazgul@apollo.uucp           ### (617) 641-3722 300/1200/2400 ###
I'm not sure which upsets me more; that people are so unwilling to accept       responsibility for their own actions, or that they are so eager to regulate     everyone else's.

bennett@vlsisj.VLSI.COM (Michael Bennett) (04/07/88)

In article <8803241941.AA09455@ELI.CS.YALE.EDU> hanks-steven@YALE.ARPA (Steven Hanks) writes:
>executing the following shell script produces weird 
>results:
>     #!/com/sh
>     eon
>     truevar :=  true
>     falsevar := false
>     if ^falsevar     then args "yes" else args "no" endif
This line doesn't work right.  (Output is 'yes')

>     if ((^falsevar))     then args "yes" else args "no" endif
And this one does.  (Output is 'no')

My experiment yielded the same results.  I'll bet DOMAIN/IX is interfering.
In /bin are scripts called true and false which return (exit 0) and
(exit 1) respectively.  This works fine for /bin/csh, but not for /com/sh
since the /com/sh command exit is for exiting loops, not exiting shells.
Thus, when /com/sh interprets ^falsevar, it replaces it with the text
'false' (it may be arguable wether or not this is the appropriate action for a
boolean variable with eon), and calls the /bin/false shell which just exits a 
non-existent loop and returns with a status of true.

The line above with ((^falsevar)) works because after the text 'false' is
substituted for ^falsevar, the expression is evaluated and returns a value
of false.

My discussion assumes the DOMAIN/IX /bin directory exists and is on your
search path.  If either of these aren't true, then maybe you have a false
command somewhere else on your search path.  Try this to find out where:

$ sh -n -x <</
$_ false
$_ /

(This returns '/bin/false' for me.)

If you take this off your search path, then the first case above still
doesn't work, and returns:

?(sh) "false" - name not found (OS/naming server)

To make the first case above work the way you want, you could write /com/sh
scripts which mimic the /bin/csh scripts for true and false.  They would
have one line, (return -t) and (return -f) respectively (look at the
Apollo help file for return).

--
Michael Bennett   (408) 434-7851 (W)
ARPA: bennett@lundy1.vlsi.com    [or bennett%lundy1.vlsi.com@parcvax.xerox.com]
UUCP: lundy1!bennett@vlsisj.uucp