02:17 jgaz left 05:22 discord-raku-bot left 05:23 discord-raku-bot joined 08:09 dakkar joined 15:26 teatime left 15:28 teatime joined 16:28 samebchase left, camelia left, Tirifto left, human-blip left, thowe left 16:29 dakkar left 16:32 thowe joined, camelia joined, Tirifto joined, human-blip joined 16:33 samebchase joined
ab5tract glad my pain could bring some smiles into the world ;) 16:44
timemelon I'm getting some behaviour from regexes that I don't understand 22:30
I'm used to * and + from PCREs
echo 'words: 12345' | grep -oP '\d+' and echo 'words: 12345' | grep -oP '\d*' both return 12345 22:31
when I try echo 'words: 12345' | raku -e 'slurp.match(/\d+/).Str.say' I get 12345 just the same 22:32
but echo 'words: 12345' | raku -e 'slurp.match(/\d*/).Str.say' gives me an empty match
how come \d* doesn't match 12345? 22:33
(also: is this the most idiomatic way to use raku as a drop in grep/sed/etc) 22:36
ab5tract it matches '0 or more', so when it hits that first 'w' from words, it has successfully matched 0 times 22:47
definitely a bit of a gotcha, though, I agree 22:48
m: "words: 12345" ~~ /\D+(\d*)/ ==> say() 22:50
camelia 「words: 12345」
0 => 「12345」
ab5tract or to drive the '0 or more' rule home: 22:51
m: "words: 12345" ~~ /\D*(\d*)/ ==> say()
camelia 「words: 12345」
0 => 「12345」
timemelon ahh that makes sense thank you 22:53
I guess the difference between the grep example and that is that grep is finding the longest match while raku is finding the first match
ab5tract yeah, we tend to refer to it as the "greediness" of the regex expression 22:54
* is very gregarious, not greedy at all :) 22:55
As to the idiom, I might me more likely to use `$*IN.slurp ~~ /regex/` but it's really a matter of taste 22:58
There's also `-n` which allows: `echo "words: 12345" | raku -ne '$_ ~~ /\D*(\d*)/ ==> say()'`\ 23:01
timemelon oh I didn't know about -n, that's nice ty 23:25
is there a reason you prefer the explicit $*IN over a bare slurp? 23:27