Timeline for Capturing Groups From a Grep RegEx
Current License: CC BY-SA 4.0
30 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 9 at 16:26 | history | edited | Trevor Boyd Smith | CC BY-SA 4.0 |
added bold text to ephasize the importance of storing the regex in a variable instead of using the pattern as a string literal
|
| Dec 21, 2021 at 6:59 | comment | added | Filip Kubicz |
In such case, the BASH_REMATCH fails with *** missing separator. and you don't really know why, until you realize the buildsystem might be using sh.
|
|
| Dec 21, 2021 at 6:58 | comment | added | Filip Kubicz |
The part with grep and \K operator is great when you are using sh, not bash, for example in a buildroot package makefile.
|
|
| Nov 22, 2018 at 14:01 | history | edited | Dennis Williamson | CC BY-SA 4.0 |
clarifying comment
|
| Oct 26, 2018 at 19:26 | comment | added | Wylliam Judd | Ah! I thought those double braces were the equivalent of parentheses for an if statement, and since I have no if statement in my use case, I didn't realize I needed them. Thanks! :) | |
| Oct 26, 2018 at 19:24 | comment | added | Dennis Williamson | @WylliamJudd You also need spaces inside the double brackets just as I show in my answer. | |
| Oct 26, 2018 at 19:21 | comment | added | Wylliam Judd |
I did it both ways. "foo.bar" =~ $regex still gives -bash: foo.bar: command not found. [["foo.bar" =~ $regex]] also gives -bash: [[foo.bar: command not found Thanks for the tip on the superfluous escape.
|
|
| Oct 26, 2018 at 12:53 | comment | added | Dennis Williamson |
@WylliamJudd: There needs to be spaces around the =~ and that expression needs to be within double brackets. In brace expansions such as in your second message it's not necessary to escape characters (the dot is always literal - that's a glob, not a regex).
|
|
| Oct 26, 2018 at 4:59 | comment | added | Wylliam Judd |
Fore example regex="([A-z]+)\." "foo.bar"=~$regex -bash: foo.bar=~([A-z]+)\.: command not found
|
|
| Oct 26, 2018 at 0:33 | comment | added | Dennis Williamson | @WylliamJudd You almost certainly have a typo. Which command does it say isn't found? What version of Bash? | |
| Oct 26, 2017 at 16:51 | comment | added | Dennis Williamson |
@mdelolmo: My answer includes information about grep. It was also accepted by the OP and upvoted quite a lot. Thanks for the downvote.
|
|
| Oct 25, 2017 at 20:18 | comment | added | nmz787 | question was about GREP, not BASH | |
| Nov 22, 2016 at 10:56 | comment | added | mdelolmo | @Brandon It does work and the example is easy enough to understand. In fact, it's a great answer. You're definitely doing something wrong. | |
| Jun 7, 2016 at 18:45 | history | edited | the Tin Man | CC BY-SA 3.0 |
edited for readability and grammar and remove "Edit" and "Update".
|
| Mar 16, 2016 at 16:18 | comment | added | Dennis Williamson | @Brandon: Without a specific example, I can't be of any help. Perhaps you should post the issue as its own question. | |
| Mar 16, 2016 at 2:22 | comment | added | Brandon | I'm not using files, I've adapted it to my scenario which is a svn log to retrieve text from a commit. I have the regex, it matches using grep but it doesn't match with =~. | |
| Mar 14, 2016 at 20:34 | history | edited | Dennis Williamson | CC BY-SA 3.0 |
use an if statement for improved clarity
|
| Mar 14, 2016 at 20:31 | comment | added | Dennis Williamson |
@Brandon: Do you have files in the current directory that match the pattern? For example, touch 012_abc_03a.jpg 345_def_14b.jpg would create a couple of empty test files that the regex matches. In my answer, the regex match and its output should be part of an if statement instead of standing alone in order to avoid outputting empty results. I'll make that change in order to improve clarity.
|
|
| Mar 14, 2016 at 20:19 | comment | added | Brandon |
@DennisWilliamson 4.3.11(1)-release. I literally copied the example verbatim. echo "${name}.jpg" echos ".jpg"
|
|
| Mar 14, 2016 at 20:12 | comment | added | Dennis Williamson | @Brandon: It does work. What version of Bash are you using? Show me what you're doing that doesn't work and perhaps I can tell you why. | |
| Mar 14, 2016 at 20:02 | comment | added | Brandon | This simply doesn't work. No regex matches regardless of the regex or input string | |
| Feb 9, 2016 at 17:39 | comment | added | smaudet |
\K operator is a lifesaver, when all you wanted was a quick one-liner for your directory operation. (my specific case was look for a name in a file, and make some directories as a result). so grep -P -o "blah \K([stuffhere]+)" somefile | godosomethingwiththat
|
|
| Sep 14, 2015 at 8:41 | comment | added | jowie | However, Bash regex doesn't support lazy matching. | |
| Oct 12, 2014 at 8:03 | comment | added | Dennis Williamson | @FrancescoFrassinelli: An example is a pattern that includes white space. It's awkward to escape and you can't use quotes since that forces it from a regex to an ordinary string. The correct way to do it is to use a variable. Quotes can be used during the assignment making things much simpler. | |
| Oct 12, 2014 at 5:47 | comment | added | Francesco Frassinelli | "It's better to put the regex in a variable. Some patterns won't work if included literally." - Why does it happens? Is there a way fix them? | |
| May 11, 2014 at 21:35 | vote | accept | Isaac | ||
| Jan 9, 2014 at 12:41 | comment | added | Brandin | In this answer I want to upvote the specific line that says "It's better to put the regex in a variable. Some patterns won't work if included literally." | |
| Apr 17, 2012 at 13:13 | history | edited | Dennis Williamson | CC BY-SA 3.0 |
Additional information
|
| Apr 17, 2012 at 12:41 | history | edited | Dennis Williamson | CC BY-SA 3.0 |
Additional information
|
| Dec 12, 2009 at 2:59 | history | answered | Dennis Williamson | CC BY-SA 2.5 |