User:Lucius Chiaraviglio: Difference between revisions

Line 19:

<code>sed -E "s#([0-9]+):([0-9]+)#\[\[\1/\2\]\]#g" 23EDOintervals.txt > 23EDOintervals.new.txt</code>

The parentheses delimit the input capture groups (and note that the "+" needs to be inside each capture group or it won't work right, and if you need to look for literal parentheses you have to escape them with backslashes, same as already used with the square brackets), and the \1 and \2 indicate the output capture groups, which also gives you the option to reverse them (for instance, if the table contained the ratios inverted, which was not the case in this particular example, but is somewhat common elsewhere). Note that the capture groups replace the overall regular expression (which was represented by an ampersand in the first version of the command); this gets rid of the ampersand and its quirk, but it turns out that backslash followed by a digit does similarly strange things when looking at page history, but apparently not in a <code>...</code> block, so I had to change them to HTML form as well (convert each "\" to "&bsol;", but '''only''' in this explanatory text — if done in the <code>...</code> block, this conversion itself causes subtle ~~problem~~).

The parentheses delimit the input capture groups (and note that the "+" needs to be inside each capture group or it won't work right, and if you need to look for literal parentheses you have to escape them with backslashes, same as already used with the square brackets), and the \1 and \2 indicate the output capture groups, which also gives you the option to reverse them (for instance, if the table contained the ratios inverted, which was not the case in this particular example, but is somewhat common elsewhere). Note that the capture groups replace the overall regular expression (which was represented by an ampersand in the first version of the command); this gets rid of the ampersand and its quirk, but it turns out that backslash followed by a digit does similarly strange things when looking at page history, but apparently not in a <code>...</code> block, so I had to change them to HTML form as well (convert each "\" to "&bsol;", but '''only''' in this explanatory text — if done in the <code>...</code> block, this conversion itself causes subtle problems). Apparently, Wikitext editing and history display get '''really weird''' when you include regular expressions in them, but it looks like I have gotten it right for now.

Added: [[User:Lucius Chiaraviglio|Lucius Chiaraviglio]] ([[User talk:Lucius Chiaraviglio|talk]]) 07:20, 29 October 2025 (UTC)<br>

Last modified: [[User:Lucius Chiaraviglio|Lucius Chiaraviglio]] ([[User talk:Lucius Chiaraviglio|talk]]) 11:12, 2 January 2026 (UTC)

Last modified: [[User:Lucius Chiaraviglio|Lucius Chiaraviglio]] ([[User talk:Lucius Chiaraviglio|talk]]) 11:21, 2 January 2026 (UTC)

== Keyboard Layout Lab ==

@@ Line 19: / Line 19: @@
 <code>sed -E "s#([0-9]+):([0-9]+)#\[\[\1/\2\]\]#g" 23EDOintervals.txt > 23EDOintervals.new.txt</code>
-The parentheses delimit the input capture groups (and note that the "+" needs to be inside each capture group or it won't work right, and if you need to look for literal parentheses you have to escape them with backslashes, same as already used with the square brackets), and the &bsol;1 and &bsol;2 indicate the output capture groups, which also gives you the option to reverse them (for instance, if the table contained the ratios inverted, which was not the case in this particular example, but is somewhat common elsewhere). Note that the capture groups replace the overall regular expression (which was represented by an ampersand in the first version of the command); this gets rid of the ampersand and its quirk, but it turns out that backslash followed by a digit does similarly strange things when looking at page history, but apparently not in a &lt;code&gt;...&lt;/code&gt; block, so I had to change them to HTML form as well (convert each "&bsol;" to "&amp;bsol;", but '''only''' in this explanatory text &mdash; if done in the &lt;code&gt;...&lt;/code&gt; block, this conversion itself causes subtle problem).
+The parentheses delimit the input capture groups (and note that the "+" needs to be inside each capture group or it won't work right, and if you need to look for literal parentheses you have to escape them with backslashes, same as already used with the square brackets), and the &bsol;1 and &bsol;2 indicate the output capture groups, which also gives you the option to reverse them (for instance, if the table contained the ratios inverted, which was not the case in this particular example, but is somewhat common elsewhere). Note that the capture groups replace the overall regular expression (which was represented by an ampersand in the first version of the command); this gets rid of the ampersand and its quirk, but it turns out that backslash followed by a digit does similarly strange things when looking at page history, but apparently not in a &lt;code&gt;...&lt;/code&gt; block, so I had to change them to HTML form as well (convert each "&bsol;" to "&amp;bsol;", but '''only''' in this explanatory text &mdash; if done in the &lt;code&gt;...&lt;/code&gt; block, this conversion itself causes subtle problems). Apparently, Wikitext editing and history display get '''really weird''' when you include regular expressions in them, but it looks like I have gotten it right for now.
 Added:  [[User:Lucius Chiaraviglio|Lucius Chiaraviglio]] ([[User talk:Lucius Chiaraviglio|talk]]) 07:20, 29 October 2025 (UTC)<br>
-Last modified:  [[User:Lucius Chiaraviglio|Lucius Chiaraviglio]] ([[User talk:Lucius Chiaraviglio|talk]]) 11:12, 2 January 2026 (UTC)
+Last modified:  [[User:Lucius Chiaraviglio|Lucius Chiaraviglio]] ([[User talk:Lucius Chiaraviglio|talk]]) 11:21, 2 January 2026 (UTC)
 == Keyboard Layout Lab ==