A regex doesn't have to match the entire string. 'abcd' ~~ / bc / # 「bc」
A string has to match exactly with the smart-match. (`ff` and `fff` do smart-match) 'abcd' ~~ 'bc' # False 'abcd' ~~ 'abcd' # True A string inside of a regex only makes that a single atom, it does not make it match like just a string. 'abcd' ~~ / 'bc' / # 「bc」 'aBaBaB' ~~ / aB+ / 「aB」 'aBaBaB' ~~ / "aB"+ / 「aBaBaB」 In fact a string inside of a regex doesn't do much more than square brackets. 'aBaBaB' ~~ / [aB]+ / 「aBaBaB」 If you want the regex to match fully, add a beginning of string and end of string marker. 'abcd' ~~ / ^ bc $ / # Nil 'abcd' ~~ / ^ abcd $ / # 「abcd」 --- Since `ff` can begin and end at the same time, the following is turning on and off at almost every iteration of the loop after it starts. $ raku -ne '.put if /star {print q[on ]}/ ff /start {print q[off ]}/ ;' startling.txt on star on off start on off startl on off startli on off startlin on off startling On Tue, Jul 28, 2020 at 1:43 PM William Michels <w...@caa.columbia.edu> wrote: > Thank you, Brad and Larry, for explaining the "ff" and "fff" infix > operators in Raku to me! > > I have to admit that I'm still fuzzy on the particulars between "ff" > and "fff", since I am not familiar with the sed function. I can > certainly understand how useful these functions could be to 'pull out > all PGP signatures' from a file (which was the Perl5 example given in > the Oracle Linux Blog). So I can now pull out the html "head" section > from the page _ https://raku.org/fun/ _ (saved locally as file > "fun.txt") using the following Raku code: > > user@mbook:~$ raku -ne '.put if Q[<head>] ff Q[</head>]' fun.txt > <head> > <meta charset="utf-8"> > <meta http-equiv="X-UA-Compatible" content="IE=edge"> > <meta name="viewport" content="width=device-width, initial-scale=1"> > <title>Raku is optimized for fun!</title> > > > <link href="/favicon.ico" rel="shortcut icon" type="image/x-icon"> > <link href="/bootstrap/css/bootstrap.min.css" rel="stylesheet"> > <link href="/bootstrap/css/bootstrap-theme.min.css" rel="stylesheet"> > <link href="/style.css?v=1" rel="stylesheet"> > > </head> > user@mbook:~$ > > What I'm less clear on is how the code below is functioning. I first > print out file named "startling.txt" with 'cat': it's supposed to > stand in for a text delimited linewise by "header 1", "header 2", etc. > After the 'cat' example, I show three examples with Perl(v5.26.3) and > three examples with Raku(2020.06), generally comparing literal vs > regex arguments. > > The first two Perl5 examples returns nothing; the third Perl5 example > returns everything after the "star" line. For the Raku code, the > 'DWIMmiest' output below is the first Raku example, which returns two > lines, "star" and "start". This is what I expected/desired. But I'm > not really understanding what's happening with the other 2 Raku > examples (which return everything after the "star" line): > > user@mbook:~$ cat startling.txt > s > st > sta > star > start > startl > startli > startlin > startling > > user@mbook:~$ perl -nE 'print if "star" .. "start" ;' startling.txt > user@mbook:~$ perl -nE 'print if /"star"/ .. /"start"/ ;' startling.txt > user@mbook:~$ perl -nE 'print if /star/ .. /start/ ;' startling.txt > star > start > startl > startli > startlin > startling > user@mbook:~$ raku -ne '.put if "star" ff "start" ;' startling.txt > star > start > user@mbook:~$ raku -ne '.put if /"star"/ ff /"start"/ ;' startling.txt > star > start > startl > startli > startlin > startling > user@mbook:~$ raku -ne '.put if /star/ ff /start/ ;' startling.txt > star > start > startl > startli > startlin > startling > user@mbook:~$ > > I'm all in favor of improving the "ff" and "fff" functions in Raku > over their Perl5 counterparts, but I'm hoping to gain a better > (mnemonic?) way of remembering the expected return values with literal > vs regex arguments. > > Any assistance appreciated, Bill. > > > > > > > On Sun, Jul 26, 2020 at 10:04 AM Larry Wall <la...@wall.org> wrote: > > > > On Sat, Jul 25, 2020 at 04:32:02PM -0500, Brad Gilbert wrote: > > : In the above two cases ff and fff would behave identically. > > : > > : The difference shines when the beginning marker can look like the end > > : marker. > > > > The way I think of it is this: You come to the end of "ff" sooner, so > you > > do the end test immediately after passing the start test. You come to > the > > end of "fff" later, so the end test is delayed to the next iteration from > > the start test. (Same mnemonic for .. and ... in Perl, by the way, since > > ff and fff were modeled on .. and ... (in their scalar form), but we > stole > > .. and ... in Raku for ranges and sequences so we needed something else.) > > > > I suppose if you're musical you can come up with mnemonics based on "fff" > > being louder than "ff", so it echoes longer before it stops... :) > > > > Larry >