Text Recommendation

[Kevin O'Gorman]

On Mon, Apr 30, 2012 at 12:45 PM, Nils Kassube <kassube at gmx.net> wrote:
> Bahn, Nathan wrote:
>> Please accept this apology for being too vague.  I'm looking for a
>> good Linux (C.L.I.) instruction manual -- preferably one with good
>> exercises to complete.  I ask this because I'm tired of being too
>> dependent upon the G.U.I.

Please put your responses *below* the previous material, if at all
possible, like this one.

Wanting to master the CLI is a great idea.  I'm not aware of a
textbook that does this, and until about a year ago I was teaching
programming at the university level.  That does not mean it does not
exist, but that may be the case.

A couple of other observations that I hope will be helpful:
1) There is more than one "command line".  Usually the term refers to
a "shell" program, of which there are several flavors, all of which
may be present in any given system.  This is because in Unix, Linux
and Mac, the shell program is just a program -- it has no special
privileges or relationship to the rest of the system.  You can even
write your own, and I used to make my students do a small version of
that.

2) That being said, :"bash" is the default shell in most Linux distros
that I'm aware of.  The most common alternatives seem to be tcsh and
ash.  There are others.  If you have no other reason to choose one, I
would suggest bash because much of the administrative programs in
Linux are written either in bash or in Python, and Python is not
normally thought of as a shell.  The advantage of this is that you can
examine existing programs that come with your system, because bash
programs (as is common with most shells) are always just text files.

3) Most of the command-line stuff that users do at the keyboard is
simple commands and options.  These are documented in man pages, and
sometimes in info pages.  The learning curve can be pretty steep
because there are so many commands.  If you know a command exists and
know its name, the command "man <name>" is the first one you should
learn.  The first form you should use is "man man" which asks the man
command to print its own man page for you.  You will probably use
"info <name>" from time to time, but just about every info page has a
man page which says you can get more from 'info', so starting with
"man" makes sense.

4) There are a *lot* of potential commands.  For instance, on the
machine I'm running right now, there are 2757 files in the /usr/bin
directory.  All of these are potential ordinary user commands.  There
are some  more in /bin, and there are even more elsewhere.  I've been
using Unix or Linux at home since 1984, and I am probably familiar
with 10-20 percent of these.  So there are many you'll never need.

5) If you think a command exists, but are unsure of its name, you can
often find it with the "apropos" command.  If you've been paying
attention so far, you know that means I'd like you to check it out
with the "man apropos" command.

6) Shells can do enormously elaborate things.  You'll probably never
need them, but it's nice to know they are there.  Sometimes, it's good
to know how it works.  One of my favorite assignments to students was
to write a program (in C, usually) to do exactly what I could program
in a couple of minutes (well, 15 or so) with shell commands.  I'd give
them 2 weeks, and it was not always enough.  For example, to find the
25 most common words of 4-20 letters (shortening any long ones) in all
the files in the current directory I would construct the following
multi-line command before their eyes (without the comments, but I'd
give them the commented version to work with):

for i in *           # Handle every entry in the directory
do
  if [ -f $i ]       # pick the regular files
  then
    cat $i           # put all files in the directory into the pipeline
    # cat will produce any needed error messages.
    # do not even warn about non-files.  Just skip them.
  fi
done |                      # put the file(s) into the pipeline
    sed 's/[^A-Za-z]/ /g' | # turn non-alphas into blanks
    tr ' \t' '\n\n' |       # turn blanks and tabs into newlines
    sed 's/^...$//g' |      # empty 3-letter lines
    sed 's/^..$//g' |       # empty 2-letter lines
    sed 's/^.$//g' |        # empty 1-letter lines
    grep -v '^$' |          # drop empty lines
                            # truncate long words and add a 6-digit length.
    perl -n -e 'chomp; if (m/\w{21}/) {printf
"%s%06d\n",substr($_,0,20),length($_);} else {print $_, "\n";}' |
    tr '[A-Z]' '[a-z]' |    # go lowercase
    sort |                  # sort the words
    uniq -c |               # count duplicates
    sort -n |               # sort on the counts (numeric)
                            # Rearrange the line
    perl -n -e 'm/(\d+) *(\w*)/; printf("%26s %d\n", $2, $1);' |
    tail -25              # trim to 25 most common

Many of the lines are commands in their own right.  The rest are
components of shell built-in functionality.  They are connected by the
"|" pipe symbol which sends the output of one command as input to the
next, and tells the shell to keep reading lines until it gets the next
part of the pipeline.  But all together, it can be considered a single
shell command.  It could even be written on a single line (without
comments, though).

Most of the commands in that example are ones that a good command-line
user should know, especially cat, sort, uniq, grep and tail.  perl is
the Perl language interpreter, which has its own learning curve.  Here
it is being used to format the lines.  tr is a bit special, but I've
used it a bit.  And perl could have been used to do everything I'm
using sed for, and sed also has a considerable learning curve.  I
could have made the whole thing quite a lot shorter, but only at the
cost of making it harder to understand.

Feel free to play with this as you're learning the command-line.  To
see it in action, you can remove stuff at the end to see what it
outputs without the commands you remove.  Just be careful to remove
the last "|" or add a "cat" command at the end to keep the shell happy
with the syntax.

Finally, I hope I haven't scared you off, but you will probably have
to decide just how deep you want to go into this stuff.

-- 
Kevin O'Gorman, PhD