Assisting Elise S with editing grub.cfg

[goossbears]

During today's BerkeleyLUG meetup on Jitsi, Rick M. and Michael P. (and one or two others?) were assisting Elise S. with her splash screen bootup issue on Ubuntu (yes, could've been Xubuntu or Lubuntu.)

IIRC, this involved assisting Elise with editing her computer's /boot/grub/grub.cfg startup file as the root/superuser ('sudo') so that  she and others could view the startup messages present when the computer starts loading X/L/Ubuntu.

Instead of using the slightly more difficult to use 'Vi' editor, might I suggest that 'Nano' is and would have been a better choice to use in this case? For the one or two of you reading this who weren't aware of this already, "Nano is the default terminal-based text editor in Ubuntu and many other Linux distributions" [1].

~~~~~~~~~ quoting [2] ~~~~~~~~~~~

[Nano is] part of a family of text editors that includes the more robust (but significantly more complex) vi and emacs. For most uses, nano is easy to use and it doesn't require a significant learning curve. Just as with the 1980s-era text-based word processors like WordStar, nano offers a dynamic two-line command reference at the bottom of the terminal window.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Using 'nano' likely also fulfills the role (again, in the particular case with Elise's simpler editing tasks) of the KISS Principle (see [3], [4], [5] and similar references.)

-Aaron

References/excerpts

[1]https://itsfoss.com/nano-editor-guide/

[2]https://www.lifewire.com/beginners-guide-to-nano-editor-3859002

[3]http://principles-wiki.net/principles:keep_it_simple_stupid

[4]https://people.apache.org/~fhanik/kiss.html

[5]https://www.interaction-design.org/literature/article/kiss-keep-it-simple-stupid-a-design-principle

------------------------------------------------------------------------

[tom r lopes]

She got along fine with vi. 

What we all forgot was 

sudo update-grub 

to enable the changes.  

Thomas

--
You received this message because you are subscribed to the Google Groups "BerkeleyLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to berkeleylug...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/berkeleylug/b1c7099b-be35-4be0-a6ea-98e1da701fffo%40googlegroups.com.

[Chuck Payne]

NANO = PICO 

Nano/Pico is easy, VI is on 90% Linux/Unix, I use to use Pico 100% until I took a job at a security company, once I learn vi, I have never looked back. 

:q!

To view this discussion on the web visit https://groups.google.com/d/msgid/berkeleylug/CAGpvfsqgFyD_HGsGN60P7tj_63SapX_jhv6XxKp21W9EjZT3Fw%40mail.gmail.com.

--

Terror PUP a.k.a
Chuck "PUP" Payne
-----------------------------------------
Discover it! Enjoy it! Share it! openSUSE Linux.
-----------------------------------------
openSUSE -- Terrorpup
openSUSE Ambassador/openSUSE Member
skype,twiiter,identica,friendfeed -- terrorpup
freenode(irc) --terrorpup/lupinstein
Register Linux Userid: 155363
 
openSUSE Community Member since 2008. 

[Michael Paoli]

So, yeah, sure there's nano(1):

NANO(1) General Commands Manual NANO(1)
NAME
nano - Nano's ANOther editor, an enhanced free Pico clone
SYNOPSIS
nano [options] [[+line[,column]] file]...
DESCRIPTION
nano is a small, free and friendly editor which aims to replace Pico,
the default editor included in the non-free Pine package. On top of
copying Pico's look and feel, nano also implements some missing (or
disabled by default) features in Pico, such as "search and replace" and
"go to line and column number".

And sure, it can be used to get folks up to editing files on, e.g. Linux,
quite quickly - very easy to learn/use, etc.

However, too ... vi(1) - it's the standard Linux(/Unix/BSD) text editor.
As I often say of vi:
optimized for ease of use and speed by those proficient at it
not optimized for ease of learning it

So ... it's definitely not the easiest to learn, but after becoming
reasonably proficient at it, it's highly efficient and well optimized.
E.g. my highly experienced vi fingers do stuff so fast and efficiently in
vi, that if I have to stop and slow down and try to explain what I did and
what I typed in and the command or sequence of commands I used to do
what I did - or so much as think about it in any detail - that slows me
way down. Also, often even working alongside coworkers that are quite
experienced in vi (like 3+ years using vi), not too uncommonly they'll
still see what I did on screen and how quickly and are still like:
"Wow! How'd you do *that*! Show me!"
And, I've even known folks that have been using EMACS for many years and
are highly proficient at it ... then take the time to learn vi, and
after a while end up concluding that vi is the superior text editor
for use (e.g. complaining about all the EMACS keystroke inefficiencies
of all the needed reaches for the Meta key all the dang time).
Or, as is oft said, EMACS is a perfectly good operating system that
just lacks a good text editor (EMACS is loaded with stuff and huge).

So, yeah, I couldn't navigate my way through nano very quickly at all.
I'd almost always pick vi - or even ex or ed - over nano.
And for those wondering, ex and vi are the same program - just different
modes (and one can switch between those modes within the program),
and ed is somewhat similar to ex in ex mode - ed being a bit simpler
(no visual mode) and well predates ex.

Anyway, vi(1) - I'm a relative expert in it. And have given presentations
and training sessions on vi(1) ... numerous times even.
And, oooh, materials! :-)
For the latest, have a look here:
http://www.mpaoli.net/~michael/unix/vi/
Probably start by having a peek at the README file(s) within,
that quite well explains what's there.

Oh, also ...
http://www.mpaoli.net/
... not exactly a high availability site. So, if one finds it down
or inaccessible or whatever, probably just try again another hour
or another day or something like that.

> From: goossbears <acoh...@gmail.com>
> Subject: Assisting Elise S with editing grub.cfg
> Date: Sun, 12 Jul 2020 13:25:10 -0700 (PDT)

> During today's BerkeleyLUG meetup on Jitsi, Rick M. and Michael P. (and one
> or two others?) were assisting Elise S. with her splash screen bootup issue
> on Ubuntu (yes, could've been Xubuntu or Lubuntu.)
> IIRC, this involved assisting Elise with editing her computer's
> /boot/grub/grub.cfg startup file as the root/superuser ('sudo') so that
> she and others could view the startup messages present when the computer
> starts loading X/L/Ubuntu.
>
> Instead of using the slightly more difficult to use 'Vi' editor, might I
> suggest that 'Nano' is and would have been a better choice to use in this
> case? For the one or two of you reading this who weren't aware of this

> already, "Nano <https://www.nano-editor.org/> is the default terminal-based
> text editor <https://itsfoss.com/command-line-text-editors-linux/> in

[Rick Moen]

Quoting goossbears (acoh...@gmail.com):

> Instead of using the slightly more difficult to use 'Vi' editor, might I
> suggest that 'Nano' is and would have been a better choice to use in this
> case?

I almost never use nano, and would have no hope of remembering its
operations. But I can efficiently walk people through vi operations
from memory without even looking. (So can any other sysadmin.)

Also, there's _always_ some implementation of vi present on any *ix,
which is also a significant part of why it's worth learning. That is
definitely not true of nano.

Nothing against nano, mind you.

[goossbears]

Quoting 'Rick Moen' via BerkeleyLUG

I almost never use nano, and would have no hope of remembering its
operations.  But I can efficiently walk people through vi operations
from memory without even looking.  (So can any other sysadmin.)

Given vim's direct relationship to vi, that immediately brings to mind the

widely known xkcd 'Real Programmers' cartoon https://xkcd.com/378/ ;-)

[Rick Moen]

Quoting goossbears (acoh...@gmail.com):

> Given vim's direct relationship to vi, that immediately brings to mind
> the widely known xkcd 'Real Programmers' cartoon https://xkcd.com/378/
> ;-)

It definitely had to end in an emacs joke!

There's actually a good reason why programmers tend to gravitate towards
emacs, and it's different but equally compelling to the reason
sysadmins tend to gravitate towards vi: A finely tuned, personalised
emacs enviroment is a significant aid to productivity, _but_ doesn't
easily replicate from one machine to the next (or so I'm told). So,
because coders can typically concentrate on making their home machine's
environment exactly right, the net benefit of all of that tweaking is
high. Also, emacs really was designed from the get-go as a specialised
development tool for coders.

By contrast, as I was mentioning, a larval-stage sysadmin benefits
greatly from mastering the core features of a very capable but
fundamentally basic, general-purpose editor that is reliably present
everywhere the sysadmin can expect to need to be productive (i.e., all
*ix machines). It just happened to be vi that filled that niche. vi's
value lay not in being insanely great; that value lay in being both
capable and fully available in its core feature set on all systems of
interest.[1]

nano doesn't have 1/10 the core functionality that basic vi does, but
that's not really the point. nano had no opportunity to propagate into
vi's niche of being a universal *ix full-screen text editor, because vi
got there first.

(vi wasn't the first common *ix text editor, e.g., there were variously
awful and weird contenders like TECO,
https://en.wikipedia.org/wiki/TECO_(text_editor). Why those never took
off is too long a story for here.)


[1] A number of vi variants have become obscure since the early days of
Linux. One of my sentimental favourites was 'elvis', if only because,
if you exited your shell session and left a file open in /usr/bin/elvis,
you received e-mail about that from elvis. Punch line: You thereby
received proof that elvis is alive!

See: http://www.linfo.org/vi/clones.html

Because of overshadowing of BSD legal rights by the AT&T v. UC Regents
lawsuit, for a very long time, Bill Joy's original vi implementation,
first released for 1BSD in 1976, was assumed to be AT&T-proprietary, and
so was shunned by free-software Unixes. The first absolutely complete
from-scratch vi clone was Keith Bostic's nvi (1994), based in part on
Steve Kirkendall's 'elvis', was immediately adopted as the standard 'vi'
by the BSDs and by many Linux users (including Michael Paoli), and
interest in Bill Joy's original waned. Although primordial vi was
-eventually- made available under a BSD-ish licence
http://www.mckusick.com/csrg/calder-lic.pdf) as 'Traditional Vi'
starting in 2002 (http://ex-vi.cvs.sourceforge.net), it's not clear that
anyone cared much, as it had long been supplanted.

[Michael Paoli]

> From: "'Rick Moen' via BerkeleyLUG" <berke...@googlegroups.com>
> Subject: Re: Assisting Elise S with editing grub.cfg
> Date: Mon, 20 Jul 2020 23:16:13 -0700

> benefits
> greatly from mastering the core features of a very capable but
> fundamentally basic, general-purpose editor that is reliably present
> everywhere the sysadmin can expect to need to be productive (i.e., all
> *ix machines). It just happened to be vi that filled that niche. vi's
> value lay not in being insanely great; that value lay in being both
> capable and fully available in its core feature set on all systems of
> interest.

Naw. ;-) vi(1) is insanely great! :-) It's THE best text editor.
It does exactly what it's supposed to do, and highly efficiently so,
no more*, no less. It's pretty lean for what it does, helluva lot
smaller than EMACS (but emacs will also make you a fruit smoothie,
but that's bloat, not text editing), and a reasonably true vi(1)
such as nvi - which is also the vi on BSD ... is even a heck of
a lot smaller (by about a factor of 10) than vim, because, well,
vim ... adds a whole lot 'o cruft that goes way beyond
text editing.

*Well, other than standard Unix philosophy - not only do well that which
you do, and don't add other cruft, but most notably also, play well with
others ... input/output, writing files - simple text format, getting
data in and out (reading from files, commands, writing to files, commands,
taking line(s) within buffer - one, all, or any contiguous set,
running them through a program and replacing those lines with the
output of program (shell, perl, sed, awk, sort, spell, ... whatever you
want).

So, yes, vi(1) ... highly standardized
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html
on most any *nix system,
and exceedingly well optimized for use at editing text,
and even more so generally in the context of Unix or the like
(Linux, BSD, ...).

Mmmm... yummy:
http://www.mpaoli.net/~michael/unix/vi/
vim? Meh. Can mostly coerce it to do the job of vi,
but often pretty dang annoying:
http://www.mpaoli.net/~michael/linux/vim/vim_annoyances.txt
Yeah, vim mostly slows down those that are highly to exceedingly
experienced with vi by ... well, ... not behaving in nearly as closely
the customary expected behavior of vi. Among vim's many
faults, it's not nearly keystroke-for-keystroke compatible
with vi ... and yeah, I know, it has a "compatible" mode ...
it's still not very compatible. But for those not so
familiar with vi, they might mostly never know the difference,
and vim will still allow one to do the basic vi editing functions,
not not behaving and responding in quite (and certainly not exactly)
the same ways.

[Alan Davis]

Jumping in for a moment to the Vi vs Nano vs Emacs debate:

I am not a programmer.  I have not learned vi.  Nano is enough for config files.  Vi reminds me of the Dvorak keyboard: an entire different muscle memory adventure.  Someday maybe.

My point is here:  Emacs had me instantly at the instant access to an info manual.   Secondarily, but ultimately more important: I can write little elisp utilities for my text editing requirements (for example editing a flat list of items separated by an arbitrary delimiter, maybe "|", I wrote  a tool to slide that delimiter on all lines to any column I might specify.   I ended up writing a bunch of little personal utilities)  AND this can be immediately assigned to a key.  

My original project was a zoological lexicon, typesetting it in LaTeX.  I discovered Unix text tools and Emacs through the Cygwin ports to WIndows, and migrated to GNU/Linux when that became known to me.  Different story. 

This special usefulness of Emacs is overlooked in most of the Vi vs Emacs debates.  One is an exacto knife, the other is a swiss army knife.  Or more.  IMHO one size does not fit all. 

I still appreciate lurking on this list, listening in to these interesting conversations.

My 2cents worth.

Alan Davis

--
You received this message because you are subscribed to the Google Groups "BerkeleyLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to berkeleylug...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/berkeleylug/20200721061613.GG3481%40linuxmafia.com.

--

The foundation of morality is to have done, once and for all, with lying.

                     ---Thomas Huxley,

                                 

[goossbears]

Quoting Alan Davis (alan3...@gmail.com):

I am not a programmer.  I have not learned vi.  Nano is enough for config files.  Vi reminds me of the Dvorak keyboard: an entire different muscle memory adventure.  Someday maybe.

This special usefulness of Emacs is overlooked in most of the Vi vs Emacs debates.  One is an exacto knife, the other is a swiss army knife.  Or more.  IMHO one size does not fit all. 

The range of available *ix text editors for config files, "competent sysadmins", and "special usefulness" for programmers/non-programmers sort of raises a related interesting point:

Is it better to learn new technologies -- when nobody may be immediately around to guide you though them ....

1) by Taking Baby Steps ?

-or-

2) by the Sink or Swim Method ?

(non-original terms :-\)

Similar in a sense to choosing a Beginners' Linux distribution, IMHO, Nano is super-easy to learn by oneself as a first Baby Step (when using the commandline/terminal) without an explicit need for taking a tutorial such as Michael P's fine vi tutorial/guide/quickrefs at http://www.mpaoli.net/~michael/unix/vi/

Emacs, on the complete opposite side of the spectrum, can cause first-time users to rapidly Sink like deadweight when they can't figure out how to Save files or even Exit the editor (happened to me too, as in "where the heck is my darn META key for crying out loud?? Arrrrgggh, stupid editor!!!!")

It's mandatory, or it really should be, for both beginner and lapsed Emacs users to take the inline Emacs tutorial ASAP!

But I'll tell you what..... after going through all the uphill struggles to finally grasp using Emacs in all its modes and customizations, it's just incredibly efficient for

so many things...

vi/vim are -- as Michael P continues emphasize for vi -- excellent more intermediary editors that are universally found on all *ix's (at least for 'vi'/'nvi' ;-)

Not exactly Baby Steps, since someone learning vi (or vim) still has to learn the few most common modes and the ':'/'ex' sequences out-of-the-box (i.e., via some sort of guide or tutorial).

But far enough away from being Thrown into the Deep End and thus Sinking by being able to essentially get up and running to perform simple tasks with minimal guidance and not getting lost in all those never-ending multiple sequences of META+<something> and/or CTRL+<something> that Emacs relies upon.

Also see part of the first posting, below the xkcd link.

 

On Mon, Jul 20, 2020 at 11:16 PM 'Rick Moen' via BerkeleyLUG <berke...@googlegroups.com> wrote:

Quoting goossbears (acoh...@gmail.com):

> Given vim's direct relationship to vi, that immediately brings to mind
> the widely known xkcd 'Real Programmers' cartoon https://xkcd.com/378/
> ;-)

 

Previously, I wrote:

Instead of using the slightly more difficult to use 'Vi' editor, might I suggest that 'Nano' is and would have been a better choice to use in this case? For the one or two of you reading this who weren't aware of this already, "Nano is the default terminal-based text editor in Ubuntu and many other Linux distributions" [1].

~~~~~~~~~ quoting [2] ~~~~~~~~~~~

[Nano is] part of a family of text editors that includes the more robust (but significantly more complex) vi and emacs. For most uses, nano is easy to use and it doesn't require a significant learning curve. Just as with the 1980s-era text-based word processors like WordStar, nano offers a dynamic two-line command reference at the bottom of the terminal window.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Using 'nano' likely also fulfills the role (again, in the particular case with Elise's simpler editing tasks) of the KISS Principle (see [3], [4], [5] and similar references.)

References/excerpts

[1]https://itsfoss.com/nano-editor-guide/

[2]https://www.lifewire.com/beginners-guide-to-nano-editor-3859002

[3]http://principles-wiki.net/principles:keep_it_simple_stupid

[4]https://people.apache.org/~fhanik/kiss.html

[5]https://www.interaction-design.org/literature/article/kiss-keep-it-simple-stupid-a-design-principle

------------------------------------------------------------------------

 

-Aaron

--

Time-Dilation Formula: observer time = proper time / sqrt(1 - (v/c)^2)

[Rick Moen]

Quoting Alan Davis (alan3...@gmail.com):

> Jumping in for a moment to the Vi vs Nano vs Emacs debate:

Ugh. Very bad sign. {sigh}

I wish you hadn't gone there. And, by the way, I wish you hadn't
signaled in advance that this was going to be drivel, via your
capitalisation.

> This special usefulness of Emacs is overlooked in most of the Vi vs
> Emacs debates.

There are no 'vi [the correct capitalisation, FYI] vs. emacs debates'.
At all. This is typically bullshit, lazy hypothesising from people
who've never bothered to live and work in the *ix community, often
reporters seeking to generate clickbait or some bored Usenet troll.
Other times, for some reason, it results from a desire to turn
everything into false and gratuitous soap opera, solely because that's
easier than thinking.

Anyone who has even a tiny fraction of a clue knows that the vi and
emacs families of text editors are both excellent editor designs, each
with multiple implementations (e.g., if you as an emacs user were
unaware of GNU emacs vs. xemacs, shame on you), that simply have
_different foci_.

All the razzing by each community of users by the other, e.g., back in
dinosaur days I'd suggest 'emacs' stands for 'Eighty Megs and Constant
Swapping' before RAM requirements outstripped that joke, or 'Emacs Makes
a Computer Slow' -- both highly traditional and ancient jokes -- would
be strictly in a spirit of friendly railery. Claiming that there is a
'debate' indicates that the speaker seriously doesn't get it, at all.

> One is an exacto knife, the other is a swiss army knife. Or
> more. IMHO one size does not fit all.

You've said approximately zero, here. Try harder. Try better.

--
Rick Moen Patriotism means to stand by the country. It does not mean
ri...@linuxmafia.com to stand by the president or any other public official.
McQ! (4x80) -- Theodore Roosevelt