<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Good rant!<br>
    <br>
    As someone your age who switched from aerospace engineering to
    computers in the early 80s, I feel your pain.  Big time.<br>
    <br>
    I started using *NIX in the mid-80s, starting with the old Sun-2
    workstations.  I remember thinking that vi seemed to be a major
    throwback compared to the edt editor I had been using on the DEC
    VAX/VMS system.  But then, I didn't have a choice if I was going to
    work on a *NIX machine.<br>
    <br>
    I quickly learned that there are several fundamental concepts that
    you need to understand to be successful with *NIX:  shell scripting,
    regular expressions, and find.<br>
    <br>
    There are two major lines of development for regular expressions,
    the ones that originated out of Bell Labs, and the extensions to
    them coming from the Perl language which I think formed much of the
    basis for the POSIX regular expression library.  Sed came from Bell
    Labs, so it follows the BL conventions.<br>
    <br>
    In any event, the definitive documentation on regular expressions
    should be the man pages, although they can be very dry and difficult
    to decypher.  Much technical documentation is written using many
    levels of processing, so the author may have had the correct syntax
    in their original writings, but through the multi-level processing
    to go from the text to the presentation, something was missed by the
    proofreaders (if any).<br>
    <br>
    In a bigger sense, though, this is just the par for the course. 
    Much of what we use in the open source world is written by
    volunteers or sponsored by corporations that need to obtain revenue
    from their efforts.  Documentation is seen as a "cost-center" whose
    magnitude is meant to be minimized in corporate revenue optimization
    efforts.  Thus, what we save in software licensing fees, we may
    spend with our time desperately searching the web for nuggets that
    tell us why a reasonable (to us) command does not do what we think
    it should, or even HOW to do something in the first place.<br>
    <br>
    Of course I could take the conspiracy theory approach and say it's a
    revenue optimization effort by Google, Yahoo and Microsoft to
    maximize the number of searches per line of code.  Before Google
    came on line, everything was well documented, organized, and
    indexed, so one could find answers very quickly.  I worked for a
    while on an IBM mainframe many years ago, and any time I had to look
    up an error code, I could quickly go over to the three-foot long
    printed manual on the table in the office, flip open to the section
    2 ft, 3 1/2 inches from the left side, and look up that error
    number.  It had a description of the error and what to do about it. 
    Of course the reason it was so well organized is that one needed it
    because the mainframe was such a pain to work on.<br>
    <br>
    But I digress.<br>
    <br>
    Documentation has always been the bane of developers.  Very few of
    us are good at both coding and documenting our work.  With the
    recent trend to agile development, the attitude seems to emphasize
    coding even more to the point where it's generated automagically
    (through probably even more layers than before) from our source code
    and the few comments we sprinkle amongst the meat of our code.<br>
    <br>
    I do feel your pain and have felt it for years, many years.<br>
    <br>
    Good luck,<br>
    Steve<br>
    <br>
    <div class="moz-cite-prefix">On 05/17/2015 02:11 PM, Steve VanSlyck
      wrote:<br>
    </div>
    <blockquote
cite="mid:1431871889.933079.270835985.6DCC3496@webmail.messagingengine.com"
      type="cite">
      <pre wrap="">Rant follows. If you're not up for some immaturity on a Sunday morning,
it's OK, please press delete. Before that, once again, please accept my
appreciation for the tons of help you guys are giving me. I trust some
of you will relate.

Jim, who is always here, always helpful, asked me some good questions
about my one-liner,

sed -i.bak 's:(^Defaults\s*Env_reset\s*)$:$1\nDefaults
editor=/bin/nano:' ./sudoers

, one of which was why "$1?"

For the "replace" portion of sed, I was trying to find out how to return
the result of the last search and $1 seemed to be the right way to do
it. I saw what I thought was a authoritative page on this but cannot
find it now. One that I did find is
<a class="moz-txt-link-freetext" href="http://stackoverflow.com/questions/2890700/backreferences-syntax-in-replacement-strings-why-dollar-sign">http://stackoverflow.com/questions/2890700/backreferences-syntax-in-replacement-strings-why-dollar-sign</a>
.

Everything I'm readying about regular expressions talks about this
engine does it this way and that engine does it that way and it's all
very confusing and frustrating. None of the "engines" are
fedora-based bash, so I have no idea which engine's requirements I'm
supposed to go by.

On top of this I have to struggle with a problem endemic to technical
writing and which is far too common: writers who state a rule and then
give examples inconsistent with the rule just described!

This makes me scream. I've seen it in so-called textbooks and
well-regarded non text-books on mathematics such as 1089 and All That.
It usually results in uncharitable thoughts about the author followed by
some profanity and an addition to the trash can. On grymoire.com, for
example, Bruce Barnett writes, "If you need to match a "^" at the
beginning of the line, or a "$" at the end of a line, you must escape
the special character with a backslash." Hard rule, got it, I'm good,
let's read on...and then he follows it up with THESE examples!:

^A matches "A" at the beginning of a line A$ matches "A" at the end of
a line A^ matches "A^" anywhere on a line $A matches "$A" anywhere on a
line ^^ matches "^" at the beginning of a line $$ matches "$" at the
end of a line

WT#! It maybe would've killed him to mention escaping the character OR
doubling it, and then give BOTH examples?:

^^ or \^ matches "^" at the beginning of a line $$ or \$ matches "$" at
the end of a line

How are we supposed to learn anything if we can't trust our teachers!

I'm almost 60. I approach this stuff in good faith, with no math
training beyond high school, no programming experience beyond Excel, a
little BASIC as a teenager* in the 70's, and an introduction to Visual
Basic course at DeVry in 2003 (where I got high marks for both coding
and commenting), and every time I try to learn something I run into
walls because the teachers won't do in English what they do in code!

Anyway, thank you for listening. I'm not going to give up this time.



Steve

*This was the first time I gave up on trying to learn something by
reading the documentation. The page in my TRS-80 manual said something
like print(string) and absolutely NOWHERE in the book was there the
least little hint that the correct syntax was print("string"). I
struggled with it for days, believing those people, before finally
giving up. To my credit, I did not blame myself.



</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
colug-432 mailing list
<a class="moz-txt-link-abbreviated" href="mailto:colug-432@colug.net">colug-432@colug.net</a>
<a class="moz-txt-link-freetext" href="http://lists.colug.net/mailman/listinfo/colug-432">http://lists.colug.net/mailman/listinfo/colug-432</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>