On Tue, Sep 1, 2020 at 8:27 AM Brian Duggan <bdug...@matatu.org> wrote:
>
> On Monday, August 31, Bruce Gray wrote:
> > I finally settled on using `try` instead of numeric coercion, because
> > if I am not golfing, I think `try` makes the grep look more like
> > “filter out the non-numbers” instead of “get rid of the zero values”.
>
> Another option is to use 'val' -- which parses it as a literal --
>
> $ raku -e 'say @*ARGS.map: { val($_) ~~ Numeric }' 1 2 3 a 1e10
> (True True True False True)
>
> Brian
>
I just wanted to point out to Radhakrishnan that Raku appears to do a good
job of weeding out erroneous "number-like" input, but using the approach
below Raku (as a feature) will accept "1_000" or "1_000_000" etc. as valid
numeric input:
~$ raku -e 'say @*ARGS.grep(*.Rat).sum;' 0 100 200 300 apples 400oranges
2kilos 18.7876
618.7876
~$ raku -e 'say @*ARGS.grep(*.Rat).sum;' 0-0 100 200 300 apples 400oranges
2kilos 18.7876
618.7876
~$ raku -e 'say @*ARGS.grep(*.Rat).sum;' 0/0 100 200 300 apples 400oranges
2kilos 18.7876
618.7876
~$ raku -e 'say @*ARGS.grep(*.Rat).sum;' 10/0 100 200 300 apples
400oranges 2kilos 18.7876
Attempt to divide by zero when coercing Rational to Str
in block <unit> at -e line 1
~$ raku -e 'say @*ARGS.grep(*.Rat).sum;' 5-0 100 200 300 apples 400oranges
2kilos 18.7876
618.7876
~$ raku -e 'say @*ARGS.grep(*.Rat).sum;' 100 200 300 apples 400oranges
2kilos 18.7876
618.7876
~$ raku -e 'say @*ARGS.grep(*.Rat).sum;' -100 200 300 apples 400oranges
2kilos 18.7876
418.7876
~$ raku -e 'say @*ARGS.grep(*.Rat).sum;' --100 200 300 apples 400oranges
2kilos 18.7876
518.7876
~$ raku -e 'say @*ARGS.grep(*.Rat).sum;' 1_000 200 300 apples 400oranges
2kilos 18.7876
1518.7876
~$
So, this all brings up the question of @*ARGS safety. Bruce said that the
shell (bash, ksh, whatever) is responsible for feeding arguments to Raku.
Are there any safety-traps lurking with one @*ARGS approach versus another?
I'm sifting through two articles right now, one by brian d foy entitled
"Quoting the Shell" and another by the author of a new shell called "Oil
shell", which (I presume) will be more secure than existing shells:
"Quoting the Shell"
https://www.perl.com/article/quoting-the-shell/
"Why Create a New Unix Shell?"
https://www.oilshell.org/blog/2018/01/28.html
https://www.oilshell.org/
Also, a little more reference/best-practices here:
"Filenames and Pathnames in Shell: How to do it Correctly"
https://dwheeler.com/essays/filenames-in-shell.html
"Bash Pitfalls"
https://mywiki.wooledge.org/BashPitfalls
"Writing Safe Shell Scripts"
https://sipb.mit.edu/doc/safe-shell/
"Shell Style Guide"
https://google.github.io/styleguide/shellguide.html
"Tips on Good Shell Programming Practices"
https://www.computerworld.com/article/2794462/tips-on-good-shell-programming-practices.html
Best, Bill.
