
The Command Line Crash Course - unmole
http://cli.learncodethehardway.org/
======
zedshaw
Well, pleasant surprise people are finding this book. Heads up, it'll be
getting a little update soon so that it matches the version that is now an
appendix in Learn Python The Hard Way. I stripped out a few commands that
weren't as useful and also added some more help on what to do when you get
stuck (what I call the "reset"). Check out
[http://learnpythonthehardway.org/book/appendixa.html](http://learnpythonthehardway.org/book/appendixa.html)
for the newer streamlined content.

In general I found these 14 commands end up being the smallest number anyone
really needs to do basic CLI work, but keep in mind that the goal of the book
is to give someone just enough experience to be able to go through my other
books. There are plenty of more in-depth books on managing a server, so I
don't bother to duplicate their work.

If you _really_ want to learn how to manage servers and work the CLI, then
check out "UNIX and Linux System Administration Handbook (4th Edition)" by Evi
Nemeth and friends. My recommendation to people is to get a crappy computer
you don't want, put OpenBSD on it following their
[http://www.openbsd.org/faq/faq4.html](http://www.openbsd.org/faq/faq4.html)
guide exactly, use the Nemeth book to configure every service you can and then
point a security scanner at your box (like Nessus, or whatever they use
today).

Once you can setup an OpenBSD box, get services running on them, and secure
those services based on known attacks, then you can pretty much do anything.
More importantly, OpenBSD is very bare bones so you learn the core of how a
Unix system works and how to configure it, but their docs are very thorough
and complete so you can do it if you follow them accurately.

Hope that all helps.

~~~
jaseemabid
> In general I found these 14 commands end up being the smallest number anyone
> really needs to do basic CLI work..

What should an advanced user know? Everything provided by coreutils, stuff
that goes in /bin etc? Also sed, awk and common tools for simple text
processing?

~~~
zedshaw
After these commands I don't think learning a ton of more commands makes you
better at working a computer. After this, sitting down to actually setup a
working Unix box and then hardening it will teach you a _crazy_ number of
commands and things. More importantly it'll teach what all those little
processes and services do on the computer.

However, I will say that learning how to effectively use grep and sed are
probably the only big omissions from my list. But, those are outside the scope
of this little book given those commands have whole books devoted to them.

~~~
jaseemabid
Well said! Its probably the tinkering that eventually teach people that
something that is in coreutils is worth looking into.

------
WestCoastJustin
Although not as deep as Zed's books/tutoriuals. I have created several
screencasts about the topic. Basically, I show you what a UNIX-like filesystem
looks like, some common commands, and then show you man pages by example. This
should be enough to get someone going and teach them how to learn for
themselves.

Crash Course on Common Commands @ [http://sysadmincasts.com/episodes/13-crash-
course-on-common-...](http://sysadmincasts.com/episodes/13-crash-course-on-
common-commands)

Crash Course on the Filesystem Hierarchy Standard @
[http://sysadmincasts.com/episodes/12-crash-course-on-the-
fil...](http://sysadmincasts.com/episodes/12-crash-course-on-the-filesystem-
hierarchy-standard)

Crash Course on Man Pages @ [http://sysadmincasts.com/episodes/19-crash-
course-on-man-pag...](http://sysadmincasts.com/episodes/19-crash-course-on-
man-pages)

ps. there are many great HN threads about UNIX commands, here are just a few:

[https://news.ycombinator.com/item?id=6360320](https://news.ycombinator.com/item?id=6360320)

[https://news.ycombinator.com/item?id=6046682](https://news.ycombinator.com/item?id=6046682)

[https://news.ycombinator.com/item?id=5022457](https://news.ycombinator.com/item?id=5022457)

[https://news.ycombinator.com/item?id=4985393](https://news.ycombinator.com/item?id=4985393)

------
stiff
The "Unix Programming Environment" book by Kernighan and Pike is still the
best source for a UNIX command line "course". I love the elegance of this
book, I learned most of what is in it already by "osmosis" before buying it,
still love to skim it just for how masterly it is written and how nicely the
problems are approached, definitely something to aspire to.

~~~
vram22
Speaking of "The Unix Programming Environment":

I was reminded, by this comment:

[https://news.ycombinator.com/item?id=7036920](https://news.ycombinator.com/item?id=7036920)

by danso in this thread (who talked about cp and mv), that I learned, from the
K&P book (IIRC), that the commands cp, mv and ln were actually all links to
the same executable, which did the right thing based on what name it was
invoked by, as found from looking at argv[0]. Checked just now in Linux with:

cd /usr/bin ls -li cp mv ln

on SuSE Linux, but they seem to be different files now ...

The -i option to ls shows the inode number.

~~~
e12e
Well, if you "want" that, you could also have a look at busybox -- which does
cp,ls,mv and more -- in a single binary (optionally statically linked).

I actually tend to do a switch on the first argument for certain shell
scripts, such as this little thing for switching between single display on a
couple of laptops/netbooks:

    
    
        #!/usr/bin/env sh
        INTERNAL=LVDS
        EXTERNAL=VGA-0
    
        for monitor in `xrandr|grep connected|awk '{ print $1 }'`
        do
          case "${monitor}" in
            "LVDS")
              INTERNAL="LVDS"
              ;;
            "DFP1")
              EXTERNAL="DFP1"
              ;;
            "CRT1")
              EXTERNAL="CRT1"
              ;;
            "VGA-0")
              EXTERNAL="VGA-0"
              ;;
          esac
        done
    
        twoscreen()
        { 
          xrandr --output ${EXTERNAL} --auto --rotate normal --pos 0x0 \
                 --output ${INTERNAL} --auto --rotate normal --pos 768x1152
        }
    
        vgaonly()
        { 
          xrandr --output ${EXTERNAL} --auto --rotate normal --pos 0x0 \
                 --output ${INTERNAL} --off
        }
    
        laptoponly()
        { 
          xrandr --output ${INTERNAL} --auto --rotate normal --pos 0x0 --output ${EXTERNAL} --off
        }
    
        fn=`basename "$0"`
    
        case $fn in
          "twoscreens")
            twoscreen
          ;;
          "onescreen")
            laptoponly
          ;;
          "vgaonly")
            vgaonly
          ;;
          *)
            echo "Usage: vgaonly|onescreen|twoscreen"
            echo "called as: $0 ($fn)"
          ;;
        esac
             

As a side note, for those running Debian (or Ubunut, I _think_ ) there's a
couple of utilities to help search for binaries/files -- namely apt-file and
dlocate. Eg:

    
    
        apt-file search -F bin/cp #returns coreutils
        # -F does a fixed string search, otherwise you'll
        # get a list of all packages which contains files
        # that *contain* bin/cp in their name such as:
        #   passwd: /usr/sbin/cpgr
    

Dlocate works with regular expressions and an index, so it's much faster and
you can do:

    
    
        $ dlocate bin/cp\$
        coreutils: /bin/cp

~~~
vram22
>if you "want" that, you could also have a look at busybox

Don't want or need it, just mentioned it as an interesting bit of Unix
history. I guess the 3 files are not links but separate files nowadays due to
much cheaper and more plentiful disk space compared to those days.

Your script is interesting.

Didn't know about apt-file or dlocate, good to know, thanks.

>Ubunut

Sort of Freudian slip? Just kidding :)

------
robgering
Another great resource is "The Linux Command Line: A Complete Introduction." I
picked up a lot of command-line fu from this book.

[http://www.amazon.com/The-Linux-Command-Line-
Introduction/dp...](http://www.amazon.com/The-Linux-Command-Line-
Introduction/dp/1593273894/)

~~~
superchan
The Linux Command Line is definitely a good book. It's actually available for
free here if anyone is interested:
[http://linuxcommand.org/tlcl.php](http://linuxcommand.org/tlcl.php)

------
danso
Understanding the shell, both memorizing its syntax and appreciating how it
and the GUI are an abstraction of something deeper (though I find it helpful
to think of the GUI as the abstraction for he command line), is under
appreciated when it comes to learning to code, so a guide like this is really
helpful to point to.

What do people think of the shortness of the chapters? That is, having hem
cover one command each? I would lean toward combining similar concepts, such
as cp and mv, so that the higher-level capabilities, the ones that make the
shell uniquely more powerful than the GUI (such as piping), stand out
more...but maybe it's better to have things one at a time?

~~~
justincormack
The GUI is not an abstraction for the command line, it is a totally unrelated
implementation, with literally no layered code. They are both interfaces to
the kernel API, but the way they are built is very different.

------
bstar77
I find it interesting that very few people know about the "cd -" command (goto
previous directory). I find it invaluable, but never see anyone else use it
(this tutorial included).

~~~
spenuke
I didn't know this one, and glad I do now! Is it possible that the other one I
wish existed is already commonplace? I'd like to have an arg that cd's to a
directory automatically after mkdir'ing it... or mv'ing a file to a directory.

Something like:

mkdir foo -go and mv foo ~/bar -go

... Probably simple enough to script, but I guess I'm too lazy at the moment.

~~~
octo_t
function take_dir { mkdir -p "$1"; cd "$1" ; }; alias take="take_dir"

~~~
barrkel
I call my version of this function 'enter'.

------
bauer
Idea: Create Anki decks to go along with the material. Anki is flashcard
software with spaced-repetition learning.

~~~
cdr
Big fan of [https://sivers.org/srs](https://sivers.org/srs) \- would have
never started using spaced repetition without it.

------
thirdsight
Please finish the other books as well!

------
fennecfoxen
Command line crash course? I can crash your command-line real easy. :(){ ;|;&
};:

------
kmfrk
Is it me, or does the HTML version not have any "Next/Prev" pagination
buttons?

~~~
jere
Yup. I'm reading _Learn Python The Hard Way_ and it's the same.

I'm actually glad it's set up that way. I assume the paid version is more
streamlined. I can't get too upset that I have to hit an extra button to
access free content.

------
Dewie
The problem I had when I wanted to read a somewhat in-depth tutorial on Linux
/ the Linux terminal (one or both), is that the tutorial said that it assumed
that you were a sysadmin. What? I couldn't just be a regular user who has none
of the experience and few of the needs of a sysadmin? No wonder Linux has a
reputation for being needlessly impenetrable.

(I don't recall the exact tutorial or if it is representable of such tutorials
in general.)

~~~
dded
I heartily second Stiff's recommendation for Kernighan and Pike. (And being
from the 80s, it assumes more of a multi-user Unix environment as apposed to a
sysadmin p.o.v.)

