Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > exit() argument evaluation

Reply
Thread Tools

exit() argument evaluation

 
 
Dr. Peter Dintelmann
Guest
Posts: n/a
 
      09-08-2003
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

 
Reply With Quote
 
 
 
 
John W. Krahn
Guest
Posts: n/a
 
      09-08-2003
"Dr. Peter Dintelmann" wrote:
>
> 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
--
use Perl;
program
fulfillment
 
Reply With Quote
 
 
 
 
Trent Curry
Guest
Posts: n/a
 
      09-08-2003
"John W. Krahn" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Dr. Peter Dintelmann" wrote:
> >
> > 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)'


 
Reply With Quote
 
Dr. Peter Dintelmann
Guest
Posts: n/a
 
      09-10-2003
Hi John,

"John W. Krahn" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

[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


 
Reply With Quote
 
Trent Curry
Guest
Posts: n/a
 
      09-10-2003
Dr. Peter Dintelmann wrote:
> Hi John,
>
> "John W. Krahn" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>
> [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.


 
Reply With Quote
 
Quantum Mechanic
Guest
Posts: n/a
 
      09-10-2003
"Dr. Peter Dintelmann" <(E-Mail Removed)> wrote:
> 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.]
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
argument evaluation aarklon@gmail.com C Programming 12 11-05-2007 09:59 AM
[EVALUATION] - E03 - jamLang Evaluation Case Applied to Python Ilias Lazaridis Python 2 04-24-2005 05:29 PM
[EVALUATION] - E04 - jamPersist Evaluation Case Applied to Ruby Ilias Lazaridis Ruby 18 04-09-2005 04:45 PM
[EVALUATION] - E03 - jamLang Evaluation Case Applied to Ruby Ilias Lazaridis Ruby 74 04-04-2005 05:29 PM
Compile time evaluation (aka eliminating default argument hacks) Nick Coghlan Python 8 03-10-2005 11:14 PM



Advertisments