I've observed this several times: for people (sysadmins, not end users)
coming from Klickibunti systems, using the Linux commandline follows a
“reverse 80-20” rule. The first 20% of skills are the hardest to
learn, after that it's all gravy. I'm trying to identify what fundamental
concepts are usually missed by people who learn mostly by copying commands from
recipes they copy from Google search results. (If you comment: my blog sadly
eats formatting, so if you write more than a few lines it may be better to
write to your blog and trackback-ping me.)
Paths and the Working directory: Files without paths are
created/looked for in the current working directory, the same applies to the
argument of the cd command. Paths beginning with '/' are absolute,
and this is handy because it is not necessary to repeatedly cd ..
before descending to some other path. (And yes, directory names can be
concatenated to paths instead of using repeated cd commands with a single
directory name.)
Stdin/out/err and shell redirection: The typical question here
is whether | less works with this-and-that command, too. Admittedly,
stderr and stdout are not used consistently, and commands like ssh who use the
terminal instead of stdin (and for good reason) don't make this lesson
easier.
Shell commandline expansion: Shell globs and variables etc. are
expanded by the shell before calling the command. Accordingly, the rules are
the same everywhere, and this nice trick of using [A-Z]* when copying
files works for deleting files with rm, too. This is tightly linked
with the first concept shown here, and lack of understanding here directly
leads to spaces in filenames.
Regular expressions are useful. They are not just something I insist
you learn, but they actually help you do your work. They're everywhere. If
you understand grep and understand about redirection, the world is your
mollusc. Somehow related is that I can not understand how somebody can refuse to
learn a decent text editor. One that runs in the text console, so you
can use it in ssh, and one with built-in search and regex based replace. It
doesn't need to be vim (although the fact that a vi style editor is available
everywhere is an advantage.)
. is not in $PATH: This is, of course, the whole chain of
understanding what '.' is to what shell variables are, at least in
principle, to what $PATH does to executing a command in a directory,
not by going there and then running ./command but by specifying the
path to the command to the final ah-ha that using ./command actually
is specifying the path to the command (and not just “it works
that way”.)
No news is good news: Typical sign is running cp twice (ah,
we've discovered cmdline history) to make sure it works or running rm
twice to make sure that the fike is really gone.
And then there is the secret rule: Sometimes you don't want to know.
The Unix world is full of arcane details where asking why doesn't get you
anywhere (not technically, at least. Learning the history of Unix and
Unix-like systems is fun, interesting and may contribute to a deeper
unerstanding in the end.) Most programs use getopt style argument processing,
but dd is just different. The directory /usr is not a
directory where users store their data. There are sed style regex (regexes?)
and there are pcre. Firefox is called Iceweasel in Debian. There are vi style
console keys (less, view, vi, and yes, the man viewer is less) and emacs style
console keys (default bash settings, the info viewer.)
Comments