
Linux Commands In Structured Order with Detailed Reference - Walkman
http://linoxide.com/guide/linux-command-shelf.html
======
gmjosack
I'm honestly curious. Is a large portion of the Hacker News audience just less
operationally experienced compared to the programming side of things? It seems
like Linux 101 lists like this make it to the top of HN pretty regularly but
I'd equate this to a post about Python that listed for/while loops, if
statements, how to create a class, etc. Am I blinded by my own experiences or
do very basic Linux seem to do very well on this site.

~~~
skeltoac
How long were you involved with Linux before you knew everything in that list?

~~~
chadillac
I'm willing to bet there isn't but a handful of people in this community that
"knows everything on that list", remembering everything on that list is...
well, unneeded?

9/10 times when I'm using a command that isn't part of my "daily list" I'll
need to consult man pages and/or Google.

I've used xargs hundreds of times, but depending on when I used it last, I can
never remember if I need -0 or not, and is it $1 or {} or wait, no no, I'm
using awk, so it's $1, and I need to changes something... is it needle,
haystack, replacement or... hell, I'm not even sure if it's substr or just
sub... errrr.

Not to mention some of these are distro specific, in some you use service name
start, in others it's /etc/init.d/service start. Some it's adduser, others
it's useradd, etc. It's relative to the distro a lot of the times... are the
files in /usr/opt/ or /opt/... or maybe they're in /usr/local/opt/... Also
they list stuff like locate, but not updatedb. Not a single mention of dd or
shred or /etc/resolv.conf or netcat (I fucking love netcat!) or unzip (far
more likely to need to unzip an archive than add a user in your day to day
life).

We're not command libraries, we're duct tape mechanics.

[http://xkcd.com/1168/](http://xkcd.com/1168/)

edit: if you're interested in learning more... I honestly can't recommend this
book enough.

[http://www.amazon.com/Linux-System-Administration-
Handbook-E...](http://www.amazon.com/Linux-System-Administration-Handbook-
Edition/dp/0131480057)

~~~
xixixao
So is it maybe that Python is a language with much smaller surface area and
(most likely) much more consistent design, so we simply don't need a cheat
sheet like this? By rough estimate, my Mac came with over 1000 commands - no
structure, namespacing.

I love that xkcd. I really hope someone will take up the task of replacing the
UI of *nix with something better. For me, it's like Windows 8: it was a nice
idea to combine touch and traditional user interface - it just turns out to be
inferior to either being done well. Writing shell scripts is just, let's face
it, horrible, and the command line interface far from ideal. It works, it has
for decades. But it's not like there has been a lot of competition to compare
with.

Sibling is complaining about academia and universities - but again, apart from
sys admins, who don't teach, none of the academics know this stuff. Learning
and teaching Python (Java) is in some respect easier but more importantly
interesting - it just doesn't make sense to learn all these commands without
actually needing them (whoever comes up with an exercise to use them all
together gets a medal).

~~~
chadillac
I agree with your sentiment but if you find the CLI to be a lack luster
interface the only thing I can think is that you've not spent enough time
using it correctly. I was a Windows guy, then an OS X guy, then a Linux guy. I
found that I preferred CLI more than GUI's so I moved to Linux full time when
I started getting frustrated with GUI tools and Darwin ports and the like.

Now days it annoys me if a library doesn't have a CLI. Even on my personal
machines I run the least amount of GUI possible for resource and usability
purposes. I don't want a new GUI or a better CLI (zsh, csh, bash, ksh, etc. do
just fine). I just want tools that utilize it properly to support it's most
powerful functionality (pipes, output redirect, proper exit codes, etc.)

A lack of familiarity with it is no institutes fault, it's a personal fault,
if you find your self looking at a CLI interface, and then resorting to
searching Google for a GUI wrapper for that interface, the ignorance isn't due
to a failure of the CLI, it's a failure of the user being intimidated or
ignorant.

Also I have no issues writing shell scripts, I use them all the time to save
me tons of work. If you're a programmer then you really get to know your
system and you really get to customize it to your liking.

An example would be switching to i3 from Gnome/KDE. I was a long time
KDE/Gnome/XFCE user and my laptops track pad settings would never stick after
a reboot when I used the GUI tools for disabling the touchpad tap to click or
just disabling it in general (thinkpad nipples ftw). After moving to i3 and
really getting more access to the core of the system I ended writing a couple
little shell scripts for enabling disabling my touchpad for when I need/want
it. What used to be a 5 step operation (open gui > click tab > uncheck box >
click save) has now become (super+space, type disa[tab](autocomplete
disable.touchpad), enter). I have a second script to enable it again, the
contents of which are small.

#!/bin/bash

exec synclient TouchpadOff=1

~~~
zodiac
I agree that CLIs are ofter better than GUIs, but I think the point was that
the Linux CLI tools could have been designed better. For example, personally I
don't like how gzip/gunzip comes in a pair, but there's no "untar" command,
instead you must pass the -x argument to tar.

------
sparkie
I find it odd that the single most important command is absent from the list:
man (w/ -k, or apropos). The article could really do with a section 0 to
explain it.

Armed with the ability to actually find commands and RTFM, you don't need to
try and remember stupid lists of commands.

Obviously it's helpful to remember commands, particularly frequently used ones
- but you should start with the right mentality: that of being able to use
your initiative to work something out, rather than resorting to google and not
having to think.

------
D9u
Interesting how many of those commands are not compatible with FreeBSD.

------
ecma
I'm curious as to why the sheet recommends 'ps aux | grep' without bothering
to mention the self-match (and tricks to avoid it like doing grep '[f]oo')
instead of just presenting pgrep with the -f flag.

This reads like a naive user primer rather than a particularly detailed cheat
sheet. I'd highly recommend that anyone interested in improving their nix-fu
beyond what is presented in the article look at something like the Unix
toolbox[1] (which I personally still find useful and recommend frequently) and
take the time to dig through the man pages in order to learn how to use and
chain these tools.

[1] [http://cb.vu/unixtoolbox.xhtml](http://cb.vu/unixtoolbox.xhtml)

~~~
ama729
IMO "ps aux | grep" is better than pgrep, it's nicely formated and allow
option like "\--color", which allow to quickly find the option/process you
were looking for.

------
yeukhon
One of the most confusing yet important thing I learned as student from
working with Linux is the execute bit on directory. It is important not to do
_chmod -R 755 mydir_ because you will give execution bit to files as well.

[https://www.washington.edu/computing/unix/permissions.html](https://www.washington.edu/computing/unix/permissions.html)

~~~
thristian
GNU chmod lets you say *chmod -R a+X mydir" (an uppercase X) which, instead of
giving everybody execute permission on all files and directories, will give
everybody execute permission only on directories, and files that already have
some execute bit set.

~~~
e12e
That's afaik not a GNUism:

[http://www.freebsd.org/cgi/man.cgi?query=chmod](http://www.freebsd.org/cgi/man.cgi?query=chmod)

[edit: If I'm reading this right (I seldom have reason to look up Posix
things, being generally concerned with concrete implementations) -- it's
actuallly a BSDism that's been incorporated into Posix:

[http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ch...](http://pubs.opengroup.org/onlinepubs/9699919799/utilities/chmod.html)
]

~~~
ecma
That's correct, +X was adopted from BSD into POSIX.2001. There's a paragraph
in §Rationale about it.

------
e12e
Hm, no "lsb_release -a" under system? Also, I've come to rely more on ls -l
/proc/${some_pid}/fd than lsof -- but if you only have to choose one, I
suppose lsof is better.

~~~
gmjosack
lsof is much more useful when you want to see which process has a file open
rather than the inverse.

~~~
e12e
I suppose I've just gotten a better intuition from ps/top than I used to have.
I agree lsof is useful!

~~~
ecma
lsof also has some brilliant selection and filtering options. Really useful
for checking for rogue high port sockets and other obscure things.

------
clintonc
I did not know about the "last" command. Very cool resource.

------
adestefan
I really don't like to tell people about killall. Mainly because it's burned
people on non-Linux systems more than once.

------
chm
This is especially great for newcomers. Sections 4, 5 and 15 are enough to
boost a new user's confidence.

------
seanhandley
pushd and popd?

~~~
gmjosack
I couldn't immediately tell from your reply whether you didn't know about
pushd/popd or were mentioning them as something missing from the list. Since I
don't seem to see them in the posted list I'm going to assume the latter.

For anyone who is curious about pushd/popd, pushd will change your current
working directory and adds your new working directory to the top of a stack.
popd will remove the top directory from the stack and change your current
working directory to the new top of stack. This is helpful in scripts where
you need to change directories for some action and then back out to where you
were. You can also use the dirs command to list the stack.

One reason I could see omitting these from the list is that they are shell
builtins rather than external commands as the vast majority of the list is.

~~~
izietto
I use "cd -" all the time, it changes to the previous working directory

~~~
gmjosack
Yeah, whenever you cd, OLDPWD gets set to the directory you just changed from.
cd will substitute $OLDPWD when you cd to "-". Perhaps even less well know,
the shell itself will expand ~- to $OLDPWD so if you ever want to see where cd
- would take you, or just list the files from your previous working directory
you could do "echo ~-" or "ls ~-" respectively.

~~~
oftenwrong
PWD, OLDPWD, and cd - are POSIX

~- is a bashism You can add a number to navigate the pushd/popd/dirs stack
[https://www.gnu.org/software/bash/manual/bashref.html#Tilde-...](https://www.gnu.org/software/bash/manual/bashref.html#Tilde-
Expansion)

------
graublau
I'd love this for OS X.

~~~
themodelplumber
Funny, I was doing some work in iTerm2 today and I found this really nice
reference for OS X:

[http://ss64.com/osx/](http://ss64.com/osx/)

"A-Z Index of the Apple OS X Command Line"

The new one for me today was "ditto," which I immediately googled to see if
there was a linux equivalent (there is, and it seems to be 'cp -Rp --parents
src/ dest/').

Edit: Compared to the OP link I like that it doesn't truncate words
arbitrarily to wrap lines :)

Edit2: Lo and behold, a bash version:
[http://ss64.com/bash/](http://ss64.com/bash/) ...and a Windows version!
[http://ss64.com/nt/](http://ss64.com/nt/) I like to see that. Useful site,
with more at [http://ss64.com/](http://ss64.com/) (no relation to me)

