<p dir="ltr">Regarding documentation, I really wish the Linux man pages could reach the quality of the OpenBSD man pages.  Many times I am looking for examples of how a command argument is supposed to be used and many pages are lacking.  I realize documentation is the least enjoyable part if programming but clearer writing would bring huge benefit.</p>
<div class="gmail_quote">On May 17, 2015 7:10 PM,  &lt;<a href="mailto:jep200404@columbus.rr.com">jep200404@columbus.rr.com</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, 17 May 2015 10:11:29 -0400, Steve VanSlyck &lt;<a href="mailto:s.vanslyck@postpro.net">s.vanslyck@postpro.net</a>&gt; wrote:<br>
<br>
&gt; ... asked me some good questions about my one-liner,<br>
&gt;<br>
&gt; sed -i.bak &#39;s:(^Defaults\s*Env_reset\s*)$:$1\nDefaults<br>
&gt; editor=/bin/nano:&#39; ./sudoers<br>
&gt;<br>
&gt; , one of which was why &quot;$1?&quot;<br>
&gt;<br>
&gt; For the &quot;replace&quot; portion of sed, I was trying to find out how to return<br>
&gt; the result of the last search and $1 seemed to be the right way to do<br>
&gt; it. I saw what I thought was a authoritative page on this but cannot<br>
&gt; find it now. One that I did find is<br>
&gt; <a href="http://stackoverflow.com/questions/2890700/backreferences-syntax-in-replacement-strings-why-dollar-sign" target="_blank">http://stackoverflow.com/questions/2890700/backreferences-syntax-in-replacement-strings-why-dollar-sign</a><br>
<br>
That article talks about Java and Perl.<br>
Your example used sed, which predates Perl by much.<br>
I saw no direct mention of sed in that article.<br>
<br>
What has your experimentation revealed about how sed works?<br>
<br>
&gt; Everything I&#39;m readying about regular expressions talks about this<br>
&gt; engine does it this way and that engine does it that way and it&#39;s all<br>
&gt; very confusing and frustrating.<br>
<br>
Indeed. It is that way. I don&#39;t pay any attention to the<br>
underlying engines, just how each program implements regexes.<br>
Knowing what the common themes are,<br>
I often figure things out with experimentation.<br>
<br>
&gt; None of the &quot;engines&quot; are fedora-based bash,<br>
&gt; so I have no idea which engine&#39;s requirements I&#39;m<br>
&gt; supposed to go by.<br>
<br>
You have to read the manual for each program _and_ experiment<br>
to back it up. I think of shells as implementing globs, not<br>
regexes, although they might have some regex capability that<br>
I&#39;m not aware of. Learn the difference between globs and regexes.<br>
<br>
&gt; On top of this I have to struggle with a problem endemic to technical<br>
&gt; writing and which is far too common: writers who state a rule and then<br>
&gt; give examples inconsistent with the rule just described!<br>
<br>
Yup. It sucks. Experiment. Sometimes even read the source code.<br>
<br>
&gt; This makes me scream.<br>
<br>
Yup. It sucks.<br>
<br>
&gt; ^A matches &quot;A&quot; at the beginning of a line A$ matches &quot;A&quot; at the end of<br>
&gt; a line A^ matches &quot;A^&quot; anywhere on a line $A matches &quot;$A&quot; anywhere on a<br>
&gt; line ^^ matches &quot;^&quot; at the beginning of a line $$ matches &quot;$&quot; at the<br>
&gt; end of a line<br>
<br>
Those make sense to me.<br>
<br>
&gt; On <a href="http://grymoire.com" target="_blank">grymoire.com</a>, for<br>
&gt; example, Bruce Barnett writes, &quot;If you need to match a &quot;^&quot; at the<br>
&gt; beginning of the line, or a &quot;$&quot; at the end of a line, you must escape<br>
&gt; the special character with a backslash.&quot;<br>
<br>
I think he is wrong and very close to being right.<br>
Better would have been to say pattern instead of line. I.e.,<br>
<br>
    &quot;If you need to match a &quot;^&quot; at the beginning of the<br>
    pattern, or a &quot;$&quot; at the end of a pattern,<br>
    you must escape the special character with a backslash.&quot;<br>
<br>
Submit a patch to him.<br>
<br>
Books benefit from the work of a good editor.<br>
Much online stuff does not have the benefit of editors,<br>
and it shows. Often it helps to consult several online<br>
sources, and compare them.<br>
<br>
By the way, there is often more than one way to do<br>
something. An exercise can be to see how many ways<br>
one can do something.<br>
<br>
&gt; WT#! It maybe would&#39;ve killed him to mention escaping the character OR<br>
&gt; doubling it, and then give BOTH examples?:<br>
<br>
You are his editor. Submit a patch.<br>
<br>
&gt; How are we supposed to learn anything if we can&#39;t trust our teachers!<br>
<br>
By experience, which involves making mistakes and getting burned<br>
by misplaced trust. You&#39;ll develop a sense of how much to trust<br>
information. The judgement for such is highly subjective.<br>
You&#39;ll notice a correlation between the various kinds of<br>
goodness in writing with the accuracy of the information.<br>
Having suffered from poor writing, you will appreciate good<br>
writing more and more. You will pay more attention to a well<br>
written question than lesser writing. You are not alone.<br>
Others behave similarly. They are waiting for a good question.<br>
This leads back to the advice at the top of <a href="http://colug.net" target="_blank">colug.net</a>.<br>
<br>
&gt; I&#39;m almost 60. I approach this stuff in good faith, with no<br>
&gt; math training beyond high school, no programming experience<br>
&gt; beyond Excel, ...<br>
<br>
Excel experience should have been enough to make you wary. :-)<br>
<br>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -<br>
<br>
Many O&#39;Reilly books are good. Older editions are cheap.<br>
For classic Unix tools, old editions are still relevant.<br>
Consider reading the following:<br>
<br>
    sed &amp; awk by Dale Dougherty &amp; Arnold Robbins<br>
<br>
It covers regular expressions as used by those programs.<br>
<br>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -<br>
<br>
I have found many documentation errors over the years.<br>
Sometimes I later realized that the documentation was<br>
correct and that I was wrong. An Intel 8051 manual was<br>
one manual I thought was wrong, but later realized was<br>
correct. The more I studied it, the more I realized how<br>
carefully it was written, that every word was chosen well.<br>
<br>
Some authors are great. Kernighan and Ritchie wrote<br>
&quot;The C Programming Language&quot; with wit. W. Richard Stevens<br>
wrote APUE with amazing precision. A Fortran manual from<br>
IBM by anonymouse authors was excellent.<br>
_______________________________________________<br>
colug-432 mailing list<br>
<a href="mailto:colug-432@colug.net">colug-432@colug.net</a><br>
<a href="http://lists.colug.net/mailman/listinfo/colug-432" target="_blank">http://lists.colug.net/mailman/listinfo/colug-432</a><br>
</blockquote></div>