exit() argument evaluation

[Dr. Peter Dintelmann]

Hi,

perl -le 'print 4==7 ? 0 : 1'

produces "1" as output and

perl -e 'die 4==7 ? 0 : 1'

produces "1 at -e line 1.". But

perl -e 'exit 4==7 ? 0 : 1'

sets the exit code to 4 instead of 1 (using brackets around the
argument of exit() changes this).

Is there any reason for this behaviour?

Peter Dintelmann

 

[John W. Krahn]

perl -le 'print 4==7 ? 0 : 1'

produces "1" as output and

perl -e 'die 4==7 ? 0 : 1'

produces "1 at -e line 1.". But

perl -e 'exit 4==7 ? 0 : 1'

sets the exit code to 4 instead of 1 (using brackets around the
argument of exit() changes this).

Is there any reason for this behaviour?

perldoc perlop
[snip]
nonassoc named unary operators
nonassoc < > <= >= lt gt le ge
nonassoc == != <=> eq ne cmp
left &
left | ^
left &&
left ||
nonassoc .. ...
right ?:
right = += -= *= etc.
left , =>
nonassoc list operators (rightward)


exit (a named unary operator) has higher precedence than == while print
and die (list operators (rightward)) have lower precedence.


John

 

[Trent Curry]

perl -le 'print 4==7 ? 0 : 1'

produces "1" as output and

perl -e 'die 4==7 ? 0 : 1'

produces "1 at -e line 1.". But

perl -e 'exit 4==7 ? 0 : 1'

sets the exit code to 4 instead of 1 (using brackets around the
argument of exit() changes this).

Is there any reason for this behaviour?

perldoc perlop
[snip]
nonassoc named unary operators
nonassoc < > <= >= lt gt le ge
nonassoc == != <=> eq ne cmp
left &
left | ^
left &&
left ||
nonassoc .. ...
right ?:
right = += -= *= etc.
left , =>
nonassoc list operators (rightward)


exit (a named unary operator) has higher precedence than == while print
and die (list operators (rightward)) have lower precedence.

Quite right. So the moral of this story is, when in doubt, add a set of ()'s
the expression in question:

perl -e 'exit (4==7 ? 0 : 1)'

 

[Dr. Peter Dintelmann]

Hi John,


[snip]

exit (a named unary operator) has higher precedence than == while print
and die (list operators (rightward)) have lower precedence.

ok; this was a fairly stupid question, sorry. It seems that I expected
unary builtins to behave like list operators called with a one element
list. Is this counter-intuitive ;-)?

Peter

 

[Trent Curry]

Hi John,


[snip]

exit (a named unary operator) has higher precedence than == while
print and die (list operators (rightward)) have lower precedence.

ok; this was a fairly stupid question, sorry. It seems that I
expected unary builtins to behave like list operators called with
a one element list. Is this counter-intuitive ;-)?

Peter

Wel, I'd say that seems to be how it (read unary) is supposed to behave. If
you use it as you've written it in your subject lines (with the ()s ), then
that solves it.

 

[Quantum Mechanic]

ok; this was a fairly stupid question, sorry. It seems that I expected
unary builtins to behave like list operators called with a one element
list. Is this counter-intuitive ;-)?

This behavior was most likely chosen to follow the DWIM philosophy --
more often than not, you want named unary operators to grab just one
thing. If they behaved like list operators, and grabbed more than one
thing, what would they do with the extra?

Also, when it doesn't DWIM, it is more likely to generate an obvious
error, rather than eliminate parts or the whole of the following
expression. [Odd behavior is more noticeable than missing behavior.]
The result of a DDWIM [Doesn't DWIM] is more likely to be easily
associated [by the programmer] with the first "list" element, and
using parens should follow.

It might be interesting to have a pipe syntax, so you could have
written:

4==7 ? 0 : 1 | exit

[But then when 4 *does* equal 7, is the result 0, exit(0), or exit(1)?
You'd still need parens.]