Ask a Question related to PERL Miscellaneous, Design and Development.
-
Dr. Peter Dintelmann #1
exit() argument evaluation
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
Dr. Peter Dintelmann Guest
-
Evaluation Period
I thought the evaluation period is 6 weeks. But now second week into my evaluation period, it tells me to switch to developer edition. Why? I'm... -
Evaluation upgrade
We have been using the evaluation copy of windows 2003 for some time now. The evaluation period ran out a few days ago. We have purchased a retail... -
Site Evaluation Please
Completed site & need your evaluation. Thanks. Referring URLs http://www.bertmoniz.com -
Flash evaluation
Hi everyone. I am new to this newsgroup. I enjoy using flash and I have just finished a website created for two of my friends who are travelling... -
Unixware Evaluation
On Sat, Jul 19, 2003 at 08:45:06PM +0100, Graham Wharton wrote: Perhaps you might get some ideas here: http://www.opensource.org/sco-vs-ibm.html... -
John W. Krahn #2
Re: exit() argument evaluation
"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
John W. Krahn Guest
-
Trent Curry #3
Re: exit() argument evaluation
"John W. Krahn" <krahnj@acm.org> wrote in message
news:3F5C4F58.A0C4CD38@acm.org...Quite right. So the moral of this story is, when in doubt, add a set of ()'s> "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.
the expression in question:
perl -e 'exit (4==7 ? 0 : 1)'
Trent Curry Guest
-
Dr. Peter Dintelmann #4
Re: exit() argument evaluation
Hi John,
"John W. Krahn" <krahnj@acm.org> wrote in message
news:3F5C4F58.A0C4CD38@acm.org...
[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
Dr. Peter Dintelmann Guest
-
Trent Curry #5
Re: exit() argument evaluation
Dr. Peter Dintelmann wrote:
Wel, I'd say that seems to be how it (read unary) is supposed to behave. If> Hi John,
>
> "John W. Krahn" <krahnj@acm.org> wrote in message
> news:3F5C4F58.A0C4CD38@acm.org...
>
> [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
you use it as you've written it in your subject lines (with the ()s ), then
that solves it.
Trent Curry Guest
-
Quantum Mechanic #6
Re: exit() argument evaluation
"Dr. Peter Dintelmann" <peter.dintelmann@dresdner-bank.com> wrote:
This behavior was most likely chosen to follow the DWIM philosophy --> 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 ;-)?
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.]
Quantum Mechanic Guest



Reply With Quote

