[conspire] ed(1), regular expressions, lovely(?) man pages, book(s)/tutorials(!), (and shell ramblings, and ... potatoes)

[Michael Paoli]

references/excerpts & comments (in-line), etc.:

> Date: Fri, 11 May 2018 22:59:17 -0700
> From: Rick Moen <rick at linuxmafia.com>
> To: conspire at linuxmafia.com
> Subject: Re: [conspire] ed(1) book
> Message-ID: <20180512055917.GB19633 at linuxmafia.com>
>
> Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):
>> Wow, ... I mean, *and entire book*, on ed?
>
> And advertised on a very appropriate date.  ;->  (You might possibly
> have missed that small but important bit, denoting this being part of

Oops, ... I should'a caught that wee bit ... especially too with the
Manly McManface Edition.

> Date: Fri, 11 May 2018 20:55:19 -0700
> From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
> To: conspire at linuxmafia.com
> Subject: Re: [conspire] ed(1) book
> Message-ID: <20180511205519.10195us3x0g6vs00 at webmail.rawbw.com>
>
> Wow, ... I mean, *and entire book*, on ed?
>
> Well, okay, "only" 104 pages, and only $9.99 (unless one gets the
> Manly McManface Edition), that's semi-reasonable.  But still.
>
> ed(1) is highly comprehensible, albeit a bit terse.  I learned ed
> from the man page (and of course some practice) - knowing vi and/or
> ex helps, but not a requirement.  And, ... the man page for ed(1), let's
> see ... 7th edition Unix ... 5 ... yes only *5* pages!  So, ... 5 pages,
> very good (but a bit dated - but hey, it's not changed much) reference
> on ed - pretty much all one needs to know, ... or $9.99 for a 104 page

> man page ... egad, GNU takes 1,106 lines to cover it - that's about
> 17 pages.  Bloated, okay, but still, more concise than 104 pages.
>
> Oh, back with UNIX Version 7 ... the original definition for
> regular expressions at least in that version? ... all also contained within
> the mere *5 pages* that fully describes ed - *and* regular expressions.
>
> https://web.archive.org/web/20170601064537id_/http://plan9.bell-labs.com/7thEdMan/v7vol1.pdf
>
>> Date: Sat, 21 Apr 2018 02:03:33 -0700
>> From: Rick Moen <rick at linuxmafia.com>
>> To: conspire at linuxmafia.com
>> Subject: [conspire] nixCraft Linux / UNIX Newsletter
>> Message-ID: <20180421090333.GA15469 at linuxmafia.com>
>>
>> ----- Forwarded message from "[RSS/Feed] nixCraft: Linux Tips,
>> Hacks, Tutorials, And Ideas In Blog Format" -----
>>
>> Book review: Ed Mastery
>>
>> Posted: 01 Apr 2018 02:09 AM PDT
>> https://www.cyberciti.biz/reviews/book-review-ed-mastery/

But in any case :-) ed(1) may be quite deserving of its own
(small) book, ... oh, say like maybe 25 pages tops?  Okay, small
chapter somewhere?  (probably been done ... many times?).

And, ... man pages are a *great* way to learn ... man pages are a *horrible*
way to learn.  Rick and I often have differing opinions there ;-) ...
sometimes we're both right, ... sometimes even simultaneously, sometimes
not ... and sometimes quite depends on context.

So, ... I reread the ed(1) man page ... from ye olde UNIX Version 7
(circa 1979).  Yes, only 5 pages, and *mostly* quite comprehensible.
But for the kinder gentler introduction ...

Advanced Editing on UNIX - Brian W. Kernighan
circa 1979, from same series of documents (2a man pages section)
https://web.archive.org/web/20170601064539id_/http://plan9.bell-labs.com/7thEdMan/v7vol2a.pdf
Makes for a perfectly fine (but yes, of course, a bit dated - but
*still* mostly highly applicable) tutorial introduction to ed(1),
and ... *only 15 pages*!  So, ... why would one need a 25 page
book, when there's a perfectly good 15 page tutorial?

... typed ... yeah, a bit dated, ... that'd be your Teletype ASR-33
typing stuff out at you ... think printed/displayed when they mention
typed.

Speaking of which ... regular expressions :-)
Oh, yeah, sure, ... see also:
http://www.rawbw.com/~mp/unix/regular_expressions/
(a pretty good intro if I do say so myself ... totally
biased opinion, though ;-) ... but that's just the "slides",
really works much better with author doing the presentation/talk
along with the slides ... okay, another biased opinion)

So, back to ye olde ed(1) man pages, and regular expressions, ... yes
I reread it.  :-)  And it's a *wonderfully* concise description/definition
set for regular expressions ... uhm, for certain definitions of wonderfully.
;-)  Okay, so it's written for nerds by nerds.
Yes, it's got the entire (then) definition and description of regular
expressions contained within *only 2 pages*!!!  Heck, it may well fit on
only *one page* - if the stuff before and after regular expressions were
removed.  But, for the nerd wanting their brain seriously tickled and/or
exercised ... yeah, that'd be the bit to read - *that* definition of
regular expressions.  It makes **very** heavy use of recursion!
"In order to understand recursion, you must first understand recursion."
~ Anonymous
And ... not surprising that - likely man page not only mostly targeted for
nerds and written by nerd(s) ... but probably written by person who
coded up the regular expression code in ed(1) itself ... which itself
very highly uses recursion.  In fact there's a book - I think the title
is "Beautiful Code" or something like that, that has a chapter or so
on that original regular expression code ... a very concise small bit
of code ... that also heavily uses recursion.  And, ... if you thought
the pageish description of regular expressions on ye olde circa 1979
man page for ed(1) was concise, small, and recursive, that ain't nothin'
compared to the code itself.  A very dense small highly recursive set of
code - that's also exceedingly efficient.  And, well, only takes about
a good chapter of book to well explain it (hopefully the original source
code was reasonably well commented?  I don't recall if the book bothered
to include any original source code comments for that bit of code ... or
if there were any or much of any around that bit of code).

Anyway, thinking of regular expressions and tutorials ... the aforementioned
Advanced Editing on UNIX - Brian W. Kernighan
does a pretty fair and much more human readable version of rather well
covering regular expressions.

And yes, I do semi-regularly refer folks to that old ("ancient")
UNIX Version 7 documentation.  Why?  Because a lot of it is still quite
relevant, and often the most important stuff in the current, was mostly
present "way back then", and "way back then" it didn't have nearly so
many bells and whistles and distractions and bloat added onto it.
E.g. sh(1) - only 6(!) pages.  Often one can learn most of the core
essentials in a much shorter more concise reference.  Okay, sure,
1979, that's pretty dated, but for current, dash(1) - man pages there,
helluva lot more concise and devoid of the bloat of bash(1), while
still being very human-friendly for the reading, and nice and current.
Even the POSIX definition/description/standard for the sh shell is quite
highly readable and *reasonably* concise.

So, yes, e.g. bash(1) ... most of what's in there one will never need, and
probably never need to know (but good to have the bash(1) man page if you
do ever run into it ... e.g. within the last couple weeks, actually had
multiple people run across <<< in bash(1) ... essential?  Hell no.  It
basically saves a couple newlines in code ... and for that they add yet a
whole new (non-standard) feature?  Whatev's.)  Although I must admit, bash
has *one* feature I think is great that I'd like to see added to POSIX, ...
but *only* one:
<(...) >(...)
Having that is very handy, not having it (when one wants/needs it) can be
worked around, but is a hassle - e.g. involving temporary named pipes and
handling all that and cleanup thereof manually in one's code.  But yeah,
that's the *only* *programming* feature I've seen that bash has added that's
worthy of inclusion beyond basic POSIX sh or dash or such.  "Of course"
there's also great stuff for *interactive* use, ... but the bits of that
that are actually quite useful have been around since the Korn shell,
and I've yet to see bash having added anything to that that is really all
that great or even a "to die for" feature or the like that one really
needs to be useful/effective/efficient in interactive use.  Note also that
for Korn shell, it - at least compared to some versions of pdksh and similar,
ye original Korn shell highly well handled command history editing ... some
similar shells (including bash!!!) don't get that *quite* right.  Bash comes
*pretty* close to implementing that very well ... if one tweaks some
non-default option settings, ... e.g. lithist.

> Date: Fri, 11 May 2018 21:39:38 -0700
> From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
> Subject: [conspire] Michael Paoli @ Cabal 2018-05-12
> Message-ID: <20180511213938.430834apeemclr0g at webmail.rawbw.com>
>
> Food ... I'm planning to bring some:
>
> And also ... some potato something or other.  I'm thinkin'
> something in the range of baked potato wedges (potatoes cut
> into quarters length-wise, bit of oil, and baked), or wedge
> fries.  In any case, I'll bring, along with that, sour cream

Potatoes ... I think I'm leaning towards quartered length-wise, bit 'o oil,
and baked.  But I reserve the right to change my mind (at least before
the cooking is done).

potatoes --quantity=N --baked --quartered=length-wise --with-oil \
   --oven=conventional --oven-option=natural-gas --oven-temp=400F \
   --time=til-golden-brown

I suspect writing the man page would be easier than coding up the robot
to make them ... well, today anyway, ... 10 or 15 years from now might be
the other way around.