The README seems to make it clear that increased finger exercise is an advantage (steroids are used for increasing muscle mass, after all).
Instead of just typing
rg '\bfoo\b'
rak '/ << foo >> /'
rg -B2 -A2 foo
rg -C2 foo
rak foo --before=2 --after=2
rg 'foo.*bar|bar.*foo'
rak '{.contains("foo") && .contains("bar")}'
Okay, I haven't actually tried it (and the README doesn't say how to), and rak does have a bunch of features and capabilities ripgrep doesn't have, but those first examples are not very inspiring after the big initial claim.
The examples are all undeniably verbose, but the source shows that many short options are also supported, specifically to copy those you would expect if migrating from the alternatives: https://github.com/lizmat/App-Rak/blob/main/lib/App/Rak.raku...
So
will do what you expect.[Edited to add] Also, the `\b...\b` form is shorter with rak - as the README also states where it documents this pattern form:
> §string
> If the pattern starts with §, then it indicates that the string should occur as a word (with word-boundaris on both ends) in the item. Basically a shortcut to specifying string --type=words. Any --smartcase, --smartmark, --ignorecase or --ignoremark arguments will be honoured.
Yes, I'm mainly complaining at the choice of examples, which don't seem to back up the claim of being "rg on steroids" at all.
Typing § is not very easy on most keyboards, and is actually impossible on some keyboard-OS combinations (including mine): https://en.wikipedia.org/wiki/Section_sign#Keyboard_entry
Some diversity doesn't hurt, though. On my keyboard, it's actually easier to type than the backslash for starters.
> §string
> If the pattern starts with §,
Is it April 1st already?!
Raku embraces Unicode in a big way, and probably influenced this decision.
I wonder if keyboards in the future will settle on a way to provide access to more characters, than is currently common.
Fwiw, § is ASCII code 167, the "Section symbol". Long been used as a record separator and section marker.
I agree the keyboard thing is really annoying. Maybe the West should investigate the efforts China has put into different typing systems.
That's not correct. ASCII has only 128 codepoints and its maximum value is 127 or 0x7F. Code 167 is not part of ASCII. You're probably thinking of ISO 8859-1.
U+00A7 (codepoint 167) is also the Unicode codepoint for §. Its use on this very web page is via Unicode and the UTF-8 encoding as the bytes \xC2\xA7.
(This is meant as a narrow correction. It doesn't really change the broader point that § is not exactly easy to type on most keyboards. Whether its ASCII or not.)
Sorry, you're right. I guess I meant 8859-1 as opposed to Windows codepages or Unicode-exclusive. My Western bias is showing as I don't know if there are old locales that wouldn't have it that would affect any international users, but I assume not?
FWIW, on some MacBook Pro keyboards, the § is right next to 1:
https://keyshorts.com/blogs/blog/37615873-how-to-identify-ma...
Perhaps for further emphasis:
Yep, edited that in as you were commenting.
Come on, you can make an equally sarcastic argument about how difficult to remember and error prone regexes/short options are.
Do the "contains" example with 5 terms.
> Do the "contains" example with 5 terms.
or, if filename matches are a possibility vs My point is that despite their claim of superiority, their examples do not show any. Maybe there's a more efficient rak way to do that chain of .contains? Why not demonstrate that?$ rak '{.contains: "foo1" & "foo2" & "foo3" & "foo4" &"foo5"}'
This actually shows one of the secret powers of the Raku Programming Language: Junctions https://docs.raku.org/type/Junction
Alternately one could express this as:
$ rak '{.contains: <foo1 foo2 foo3 foo4 foo5>.all}'
Or using whatever currying: https://docs.raku.org/type/Whatever
$ rak '*.contains: <foo1 foo2 foo3 foo4 foo5>.all'
I haven't tried this in Rak proper, but based on my understanding of the README you can do something like the following:
That's a bit though; it'll match lines that contain exactly one of "foo1", "foo2", "foo3", but not zero or 2+.