User:Lucius Chiaraviglio: Difference between revisions

(One intermediate revision by the same user not shown)

Line 17:

The case for [[23edo and octave stretching]] was more complicated, because the ratios were expressed with colons instead of slashes, and I needed to change them to slashes. This required the following "sed" command using capture groups (which Google's AI actually did a decent job of explaining how to use when I didn't know the name and was trying to look up "divided regular expression"):

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

<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 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).

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]]) 10:52, 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 17: / Line 17: @@
 The case for [[23edo and octave stretching]] was more complicated, because the ratios were expressed with colons instead of slashes, and I needed to change them to slashes.  This required the following "sed" command using capture groups (which Google's AI actually did a decent job of explaining how to use when I didn't know the name and was trying to look up "divided regular expression"):
-<code>sed -E "s#([0-9]+):([0-9]+)#\[\[&bsol;1/&bsol;2\]\]#g" 23EDOintervals.txt > 23EDOintervals.new.txt</code>
+<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 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).
+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]]) 10:52, 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 ==