Re^2: octal number mysteriously changes after pass to subroutine

Thank you pryrt++

Here's another conundrum, why don't these behave the same:

perl -le '$n=0666; print $n'
[download]

438

perl -le '$n=shift; print $n' 0666
[download]

0666

Comment on Re^2: octal number mysteriously changes after pass to subroutine Select or Download Code

Replies are listed 'Best First'.
Re^3: octal number mysteriously changes after pass to subroutine by Corion (Patriarch) on Feb 01, 2023 at 19:48 UTC
The one embedded in the source code is an octal number ~~string~~ literal to Perl. The other is a string to Perl, as it comes from `@ARGV`. If you want to treat incoming parameters as octal, see the oct function. Updated: `s/number string/number literal/`, suggested by LanX	[reply] [d/l] [select]
Re^3: octal number mysteriously changes after pass to subroutine by LanX (Saint) on Feb 02, 2023 at 00:55 UTC
There are fundamental things in Perl, which might be confusing here a scalar variable can be a number or a string (or a reference ...) There are various literal notations in code literals like `"txt"` , `'txt'` , `q(txt)` , ... will produce the same string `txt` literals like 016 , 0xE , 14 will produce the same number (well integer) 14 a string might look like a literal notation of a number like `"016"` , but literal notation inside strings will not be interpreted an implicit string to number conversion will always be decimal, hence `"016" + 3 == 19` not `17` if you want another base, you need to convert the string explicitly by yourself one (dangerous) way is `eval("016") == 14` I hope it's clearer now. Cheers Rolf _{(addicted to the 𐍀𐌴𐍂𐌻 Programming Language :) Wikisyntax for the Monastery}	[reply] [d/l] [select]
Re^3: octal number mysteriously changes after pass to subroutine by ikegami (Patriarch) on Feb 01, 2023 at 21:01 UTC
Arguments are received as strings. The second is equivalent to `perl -le '$n="0666"; print $n'` [download] and `perl -le '$n=q(0666); print $n'` [download]	[reply] [d/l] [select]