in reply to (localtime)[3] vs. ((localtime)[3])

Try

print +(localtime)[4]; #or print( (localtime)[4] );

To discover why this works, enable warnings:) and then read this extract from perlfunc:print

Also be careful not to follow the print keyword with a left parenthesis unless you want the corresponding right parenthesis to terminate the arguments to the print--interpose a + or put parentheses around all the arguments.

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
If I understand your problem, I can solve it! Of course, the same can be said for you.

Replies are listed 'Best First'.
Re: (localtime)[3] vs. ((localtime)[3])
by Abigail-II (Bishop) on Sep 23, 2003 at 09:24 UTC
    Actually, you don't have to enable warnings, as the construct won't compile:
    $ perl -wle 'print(localtime)[3]' syntax error at -e line 1, near ")[" Execution of -e aborted due to compilation errors. $

    The warning you are referring to is silly. It'll trigger in constructs like:

    print (3) + 4

    but only if you have a single space between 'print' and the opening parenthesis.

    And you thought Python was evil because it gave meaning to whitespace.

    Abigail

        Initialize only two persons reacted, one was in favour of removing it, one was against removing it. So, I provided a patch, and that got more reactions. Some in favour, some against. That's of course enough reaction to not have the patch accepted. Rafael suggested that it's possible to inspect the op-tree and determine whether 'print' is used as an operand in a boolean function, and to issue the warning only then. After a well Hugo responded we though that was a good idea, and if someone would implement it, he would accept it.

        So, there is a tiny chance that in a few years, the warning won't give so many false positives anymore.

        I also got the impression that the people who were in favour of keeping the warning are people who don't write a space between the function name and the opening paren, while among the people in favour of removing the warning were people who do put a space there.

        But I have the patch, and from now on, I'll patch any perl I install so that it won't issue the warning.

        Abigail

        Turning in to a lisp monk?