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