Replying to my own question here,
The feedback I received at our latest Raku Meetup suggested that pulling in
numeric data off the bash command line is okay--just as long as you know
what you're doing. In the second example below, Raku will convert "1_000"
to Rat 1000 (previously mentioned in last email).
In the fourth, fifth, and sixth examples below, bash will perform 'brace
expansion' before sending arguments onto Raku:
~$ raku -e 'say @*ARGS.grep(*.Rat).sum;' 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
~$ raku -e 'say @*ARGS.grep(*.Rat).sum;' {1000} 200 300 apples 400oranges
2kilos 18.7876
518.7876
~$ raku -e 'say @*ARGS.grep(*.Rat).sum;' 1{10,20,30}0 200 300 apples
400oranges 2kilos 18.7876
4118.7876
~$ raku -e 'say @*ARGS.grep(*.Rat).sum;' 1{10,20,30}0
3600
~$ raku -e 'say @*ARGS.grep(*.Rat);' 1{10,20,30}0
(1100 1200 1300)
Note, pulling the same data into Raku via a literal will simply delete the
curly braces in the last two lines above. Nonetheless, it might be better
to feed data to Raku via a file (or via a literal), rather than let bash
muck with it:
~$ raku -e 'say "1{10,20,30}0".words.grep(*.Rat).sum;'
430
~$ raku -e 'say "1{10,20,30}0".words.grep(*.Rat);'
(110 20 300)
HTH, Bill.
https://www.linux.com/topic/desktop/all-about-curly-braces-bash/
On Tue, Sep 1, 2020 at 9:57 AM William Michels
wrote:
> On Tue, Sep 1, 2020 at 8:27 AM Brian Duggan 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 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.
>
