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 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 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.
> 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?
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.
I think there are several valid definitions for "advanced" in this context. While basic awk/sed knowledge is certainly useful -- if you can do the same thing in python/ruby/perl that might be fine.
Knowing a little bit about writing valid ksh/bash shell scripts (being at least aware of bash-isms) would certainly be useful for sys adm work.
My opinion is that the full gnu (and/or bsd) userland has grown so large over the years, that saying that you should know it all is probably overkill -- but knowing how to look things up (man, info) is a must.
As Zed's implied -- GNU documentation could stand to be improved vs bsd man pages -- although the info manuals can be quite useful.
I can't recommend "UNIX and Linux System Administrator Handbook" enough it has definitely helped my burgeoning career as a sysadmin. Also I've learned tremendously from zed's C, Ruby, and Python. Thanks Zed for putting all of that together. Lastly RIP Evi Nemeth, so many Sysadmins are greatly indebted to your gifts.
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.
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.
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 ...
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:
>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.
+N. I never tire of recommending K&P to wannabe Unixers. I've said to participants of Unix courses I conducted using the book, that it (and K&R - the C book) are like Sanskrit shlokas - both are concise, and sometimes have multiple layers of meaning, which one might not get all of, on a first reading.
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?
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.
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).
"cd -" and also using "cd" with no arguments to get back to $HOME are great tips. I also have a bash function called "up" to get back N directories up the hierarchy so I can do "up 5" which is like "cd ../../../../.." but much easier to type.
up () {
if [[ $# -eq 1 && "$1" -gt 0 ]] ; then
local i d
for (( i = 0; i < $1; i++ )) ; do d="../$d" ; done
cd $d
else
echo "Usage: up N"
fi
}
I'm on my phone at the moment, but I did something similar except avoided the counting. I have a shell function called `ct` for "climb tree" where you specify the name of the directory you want to climb to; calling it will place you in the first directory above cwd whose name matches the argument and in addition I wrote a bash completion module for it so I only have to type minimal characters. I'll post the source for both shortly.
Looks like I wrote the tab-completion script on my work machine. I don't have access to it right now, but if I remember when I do have access I'll pastebin that as well.
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.
# mkdir, cd into it
mkcd () {
mkdir -p "$*"
cd "$*"
}
Just copy and paste that at the end of your `.bashrc` or `.zshrc` file. You may also want to include this comment above it so you know why it’s written like that:
# from http://onethingwell.org/post/586977440/mkcd-improved
$_ in bash means the last argument of the previous command. So:
mkdir some/long/path/to/a/dir
cd $_
mv foo some/long/path/bar
cd $_
both work for what you want, and the extra keystrokes are so few that it hardly matters. The $_ is not specific to those two commands, so works for others as well, and is typically very useful because command sequences often tend to need the last argument of the previous command in the next command; un-tar-ing a .tar file and then going to the extracted directory is another example.
I don't know -- if you learn this stuff, it is presumably to use it -- so you'll get repetition from actually doing the stuff? This is quite useless knowledge if you're not going to be using the command line IMNHO (I do use the command line all the time -- I don't see why someone should learn to do that if they're not going to use it though...).
Because some people just need to get around in a shell, not obtain an unofficial doctoral on it.
Here, let me quote from the first couple paragraphs of the first page of the book:
I wrote this book really quickly as a way to bootstrap students for my other
books. Many students don't know how to use the basics of the command line
interface, and it was getting in the way of their learning.
This book is designed to be something they can complete in about a day to a
week and then get enough skill at the command line to graduate to other books.
This book isn't a book about master wizardry system administration. It's just
a quick introduction to get newbies going.
That said, I always like to see a brief introduction to commands like cut and awk, as they are tremendously helpful for pulling stuff out of text data files and they kind of show off the (simple) power of shell. But I've read the first paragraph of the first page of the book and know that wasn't Zed's goal here.
You're being pedantic and obtuse. In your world people should get an Automotive Engineering degree before driving.
Zed teaches enough CLI to allow students to accomplish the basics so they can learn Python or C. Ideally they will expand on the material and also complete the bonus assignments in the material.
And man pages suck for absolute beginners. There's too much information overload and a beginner hasn't the context to know what is useful for his immediate needs.
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.
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.)
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.)
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 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.