Editing Talk:1638: Backslashes
|
Please sign your posts with ~~~~ |
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
| Latest revision | Your text | ||
| Line 15: | Line 15: | ||
;I don't think the regex is invalid | ;I don't think the regex is invalid | ||
| − | |||
According to <tt>man grep</tt> you need to specify the <tt>-E</tt> option to use extended regex; without it unescaped parentheses are not interpreted, so they don't need to match. | According to <tt>man grep</tt> you need to specify the <tt>-E</tt> option to use extended regex; without it unescaped parentheses are not interpreted, so they don't need to match. | ||
| Line 57: | Line 56: | ||
::::: Since no-one else seemed to want to, I just restructured that paragraph to make it more clear that if anything Harry Potter was inspired by the older examples, not the other way around. Expanded the LOTR reference and added DnD. If anything Randall is likely to be referencing either the Lovecraft references, or the concept of Elder in general. [[Special:Contributions/141.101.64.173|141.101.64.173]] 11:50, 4 February 2016 (UTC) | ::::: Since no-one else seemed to want to, I just restructured that paragraph to make it more clear that if anything Harry Potter was inspired by the older examples, not the other way around. Expanded the LOTR reference and added DnD. If anything Randall is likely to be referencing either the Lovecraft references, or the concept of Elder in general. [[Special:Contributions/141.101.64.173|141.101.64.173]] 11:50, 4 February 2016 (UTC) | ||
| − | Attempting to add to the discussion: This regex is not necessarily invalid or incomprehensible. | + | Attempting to add to the discussion: This regex is not necessarily invalid or incomprehensible. It looks like he was looking for a line with a regular expression or definitely some code. You just have to work your way through the backslashes. Although it might be invalid depending on the precise rules. He has some unescaped closing brackets and closing parenthesis. If these have to always be escaped then the regex is invalid. If however you don't have to escape a closing bracket with no opening bracket, then things are fine. I'm not familiar enough with grep's regex parser to know how it handles that edge case. Presuming those unescaped paren and brackets are fine, his regex searches for: |
1. A backslash | 1. A backslash | ||
| Line 112: | Line 111: | ||
(Perhaps just something like the penultimate paragraph, if we're not entirely mistaken?) [[Special:Contributions/162.158.152.89|162.158.152.89]] 14:14, 3 February 2016 (UTC) | (Perhaps just something like the penultimate paragraph, if we're not entirely mistaken?) [[Special:Contributions/162.158.152.89|162.158.152.89]] 14:14, 3 February 2016 (UTC) | ||
| − | The regex is supposed to be looking for | + | The regex is supposed to be looking for: |
\\\ backslash | \\\ backslash | ||
[[(] [ or ( | [[(] [ or ( | ||
| Line 131: | Line 130: | ||
| − | The regex relies on several special cases (*surprise*). | + | The regex relies on several special cases (*surprise*). |
First: bash double-quote expansion (see [https://www.gnu.org/software/bash/manual/html_node/Double-Quotes.html#Double-Quotes]). Perhaps non-intuitively, \\\ followed by a character that \ doesn't escape is an escaped backslash followed by a literal backslash, effectively the same as \\\\ followed by that same non-escaped character. After bash double-quote expansion, this results in: | First: bash double-quote expansion (see [https://www.gnu.org/software/bash/manual/html_node/Double-Quotes.html#Double-Quotes]). Perhaps non-intuitively, \\\ followed by a character that \ doesn't escape is an escaped backslash followed by a literal backslash, effectively the same as \\\\ followed by that same non-escaped character. After bash double-quote expansion, this results in: | ||
| Line 171: | Line 170: | ||
;Example of a match | ;Example of a match | ||
| − | |||
First, the shell will do some escaping substitution. So, in order to easily read it, let's see what grep really receives: | First, the shell will do some escaping substitution. So, in order to easily read it, let's see what grep really receives: | ||
| Line 202: | Line 200: | ||
:You're making the same mistake Randall did: while many (most?) regex dialects use \ as escape inside a character class, this is not true for grep's default syntax. I've expanded that interpretation in my comment below, however the analysis by 108.162.228.167 is a correct explanation of how this expression is ''actually'' interpreted by grep. --[[Special:Contributions/141.101.75.185|141.101.75.185]] 15:42, 4 February 2016 (UTC) | :You're making the same mistake Randall did: while many (most?) regex dialects use \ as escape inside a character class, this is not true for grep's default syntax. I've expanded that interpretation in my comment below, however the analysis by 108.162.228.167 is a correct explanation of how this expression is ''actually'' interpreted by grep. --[[Special:Contributions/141.101.75.185|141.101.75.185]] 15:42, 4 February 2016 (UTC) | ||
| − | Your analysis is thorough and correct, however it is unlikely this is what the regex was intended to accomplish. | + | Your analysis is thorough and correct, however it is unlikely this is what the regex was intended to accomplish. More likely, Randall is more accustomed to other regex dialects such as Perl(-compatible) regex where a backslash ''does'' work to escape special characters inside a character class. Under that assumption the regex (with some whitespace inserted for readability) would break up as: |
* <code>\\ [[(]</code> an escaped opening bracket or paren | * <code>\\ [[(]</code> an escaped opening bracket or paren | ||
* <code>.*</code> anything | * <code>.*</code> anything | ||
