
The Art of Command Line - zalzal
https://github.com/jlevy/the-art-of-command-line
======
scrollaway
> To disable slow i18n routines and use traditional byte-based sort order, use
> export LC_ALL=C (in fact, consider putting this in your ~/.bashrc).

Do not. Having a non-utf8 locale means you won't be able to handle utf-8
sanely ("that's why it's faster") and it will break at the most inexplicable
times. Any non-latin1 character appearing in your prompt or command line with
this will mess its spacing up for example. Do not do not do not.

Hell I even check for it in my .zshrc:
[https://github.com/jleclanche/dotfiles/blob/master/.zshrc#L3...](https://github.com/jleclanche/dotfiles/blob/master/.zshrc#L378-L381)

Good post otherwise.

~~~
binarycrusader
I have to reiterate this; don't do it -- sort order changes and you'll run
into other mysterious issues.

It's not worth the "performance improvement".

~~~
unhammer
There are good reasons to use LC_ALL=C _for certain commands_ , especially if
you want sorting that's stable across different systems. Sometimes you want
"aa" to be before "b" even though the Norwegian UTF-8 locale puts it after "å"
(which comes after "…zæø"):

    
    
        $ echo $'a\naa\nb\nå'| LC_ALL=C sort 
        a
        aa
        b
        å
        $ echo $'a\naa\nb\nå'| LC_ALL=nn_NO.UTF-8 sort 
        a
        b
        å
        aa
    

Even worse, some characters that are byte-different collate the same:

    
    
        $ echo  $'∨\n∧'|LC_ALL=C sort -u
        ∧
        ∨
        $ echo  $'∨\n∧'|sort -u
        ∨
    

Handling Unicode sanely requires understanding some Unicode.

~~~
binarycrusader
I'm well aware of that, but in general, don't do it still applies :-)

In general, I'd never do it for performance only, it would have to involve one
of the issues you've pointed out (there are some components I build that
require it, erroneously IMO).

------
cmrx64
> StrictHostKeyChecking=no

And welcome to MITM haven. This is awful advice if you care about the first S
in SSH.

~~~
Karunamon
Depends on your circumstances, really. If you're in an environment with lots
of VM's floating around, being created, destroyed, and so on, dealing with
SSH's paranoia (why can't I just dismiss a warning about a host/key mismatch
instead of having to edit .known_hosts?) quickly becomes an exercise in
frustration for dubious security benefit. (If the enemy is on your LAN and
able to manipulate your DNS, you've already lost)

On your home box, sure. But let's not pretend there's not a reason for the
option to exist.

~~~
DDub
I use an alias to select when to, and not to, use host keys;

alias ssht='ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no'

ssht floaty.vm # does not use host key checking

ssh my.bastion.host # validates host key

Really I ought to get SSHFP records populated when my vm's are created...

------
bdamm
If you learn bash, and you learn vi, then the next most glorious addition is:

set -o vi

Then you have vi keys in your shell. And it is marvelous.

~~~
baby
or if you learn emacs you have emacs shortcuts by default in shells.

which goes against his childish comment on emacs:

> Learn Vim (vi). There's really no competition for random Linux editing (even
> if you use Emacs, a big IDE, or a modern hipster editor most of the time).

~~~
erikb
At first I thought the same as you, but then I realised that he's not talking
about your average editor, but about which editor to use if you SSH into a
random web server etc. The thing you use in a foreign environment. That's what
"random Linux editing" probably means.

~~~
omegaham
This. On your home computer, use whatever you want. If you're using all sorts
of foreign environments, you're going to want to use whatever is common to all
of them so that you don't fumble around badly trying to do basic tasks. Learn
vi. You don't have to like it, you don't have to use it on your home system,
and you don't have to learn the eleventy-billion vim-efficiency-hacks floating
around the Internet. But learn it well enough that if you have to ssh into
some server that only has vi installed on it, you aren't rendered completely
helpless. Even "Notepad Capability" is fine.

------
jwcrux
> Fluency on the command line is a skill that is in some ways archaic...

I don't see this to be the case at all. Plus, having this be the opening line
may cause people to equate archaic=I don't need this.

I'd suggest (would pull request but afk) that you remove "is a skill that is
in some ways archaic".

~~~
_jal
Agree. I've been hearing people saying the command line is archaic since
Windows 95, and probably before that. Yet somehow I (any everyone I work with,
and have worked with over the past 25 years) still works in a shell daily. I
don't understand how someone on the technical end of running large internet
services could avoid it.

Sure, GUI tools have crept in here and there. And I understand that some
toolchains mandate all-singing, all-dancing IDEs. I don't work in those areas
(the closest I've come was doing Java work for about five years and I still
lived in vi, because Eclipse makes me homicidal). And I still see our iOS
developers using `find' and `sed'.

Which isn't to say GUIs can't improve on the command line for some things. For
example, the MacOS tool "A Better Finder Rename" (despite its inability to
rename itself something less clunky) is a great tool for mass-renaming, e.g.,
photos. I have written such critters before as shell/perl/python scripts, but
pulling EXIF data and renaming files programmatically is ticky and potentially
destructive enough that I tend to write it once and then not modify it unless
it breaks. The GUI preview and regex capture display makes this much less
annoying.

~~~
lloyd-christmas
Comparing your first sentence and that of the author, you're missing what I
see as the key word: "skill". I use command line everyday. Probably most
developers do as well. But I definitely don't have "skill" in it. I think the
point is that most developers can get by with nothing more than the basics
(whatever "basics" are in the context of their work). The command line isn't
archaic, but command line as a fluency might be.

------
agumonkey
Just throwing this
[http://mywiki.wooledge.org/BashGuide](http://mywiki.wooledge.org/BashGuide)
(it's listed 2 indirections deep so will probably be missed)

Every time you have an issue with the shell, go there.

------
pella
similar for data science:
[http://datascienceatthecommandline.com/](http://datascienceatthecommandline.com/)

[https://github.com/jeroenjanssens/data-science-at-the-
comman...](https://github.com/jeroenjanssens/data-science-at-the-command-line)

------
MachinaX
The Linux Command Line (free pdf):
[http://linuxcommand.org/tlcl.php](http://linuxcommand.org/tlcl.php)

~~~
tomaac
Hosted on Sourceforge which is now blocked almost everywhere.

~~~
MachinaX
You're exactly right tomaac. Thank you for your comment.

The reason: [http://arstechnica.com/information-
technology/2015/05/source...](http://arstechnica.com/information-
technology/2015/05/sourceforge-grabs-gimp-for-windows-account-wraps-installer-
in-bundle-pushing-adware/)

------
hamburglar
The author should prepare to catch some hell for advocating 'ForwardAgent=yes'
in ssh configs.

~~~
xenophonf
I had meant to take another look at ProxyCommand
([http://heipei.github.io/2015/02/26/SSH-Agent-Forwarding-
cons...](http://heipei.github.io/2015/02/26/SSH-Agent-Forwarding-considered-
harmful/)), so thanks for the reminder!

------
webnrrd2k
If you're into the command line, I'd recommend getting a physical copy of Unix
Power Tools [1] and spending some time with it. This is a nice article, but
Unix Power Tools is better in almost every way for learning the basics (and
more) of the Unix command line. This article mentions a few more modern tools,
but Unix Power Tools has a far better explanation of what's going on.

[1] [http://www.amazon.com/Unix-Power-Tools-Third-
Edition/dp/0596...](http://www.amazon.com/Unix-Power-Tools-Third-
Edition/dp/0596003307)

------
gitaarik
One really useful shortcut I learned in bash is Ctrl-/ which is a sort of undo
for bash when composing a command. Can't really explain how it works, you
should try it out yourself.

Also really handy is Ctrl-Y, which pastes the last cut characters by Ctrl-W,
Ctrl-U or Ctrl-K.

~~~
nanny
C-/ and C-y are from readline which mimicked them (and many more) from Emacs.

------
seri
Unix tools are very powerful, but they are not as intuitive as I would like.
It would be nice if we can have an httpie for process management, one for text
manipulation, another for system stats, and so on.

~~~
AdieuToLogic
Powerful tools are rarely instinctive. Quite often, one person's obvious is
another's opaque.

------
karmicthreat
So this is tangentially related by why do people seem to push Vi? Nano is a
perfectly serviceable editor. If I need to do extensive editing I always end
up loading it into Atom, Sublime or some other editor anyway.

I've never really had to use a console editor for more than 10s of lines.

~~~
elchief
nano is super easy to use, I agree. I tried vim and gave up. Will try again.

~~~
baghira
I find it a bit irksome that when discussing command line editors, the
dichotomy appears to be be "nano vs vim".

There are other CLI editors. I'm quite partial to ne (the Nice Editor), which
has more manageable shortcuts than emacs, a command line (it's still a non-
modal editor, to be clear), macros and syntax highlighting. Also jed is not
bad. While vim (and nvim) have advantages, and certainly benefit from being
ubiquitous and having ther shortcuts replicated in other programs, users
should shop around, even on the command line.

------
stinos
_Fluency on the command line is a skill now often neglected or considered
archaic_

By whom? (honest question: even the most GUI oriented people I know reckon the
power of command line skills)

~~~
weavie
I work in a .Net house. When we had to move to front end development which
required using grunt _shock_ from the command line there was plenty of dissent
at how we were being forced back into the "dark ages".

------
barely_stubbell
I'm glad the author took time to mention sl - every sysadmin should make sure
that its installed on all the boxes they manage.

~~~
pyre
Good ole' _s_ team _l_ ocomotive command...

------
craneca0
The new csysdig curses CLI [1] unifies and replaces a bunch of the system
debugging tools listed here.

[1]
[https://github.com/draios/sysdig/wiki/Csysdig%20Overview](https://github.com/draios/sysdig/wiki/Csysdig%20Overview)

------
MarcScott
I'd never even thought about commenting a line I was half way through writing,
when suddenly realising I'd forgotten the correct arguments.

I normally end up opening another terminal and using man there.

~~~
unhammer
I do this sometimes when I want to run some command first from earlier in my
history, then the commented out command also stays in history so I can
continue with it after I've re-run the earlier command first.

------
AdieuToLogic
Much, much more can be found at:

[http://www.commandlinefu.com/commands/browse](http://www.commandlinefu.com/commands/browse)

------
hobarrera
Fun fact: alt+# is impossible on a Spanish keyboard, because alt+3 = #. So you
actually _need_ to hold alt to type the character in the first place.

------
mediocrejoker
> To locate a file by name in the current directory, find -iname _something_ .
> (or similar). To find a file anywhere by name, use locate something (but
> bear in mind updatedb my not have indexed recently created files).

I think this will glob unless you escape the asterisks. Also on my system
(debian 8) I need to put the directory to search first, or not at all:

find . -iname \ _something\_

find -iname \ _something\_

edit: hackernews ate all my asterisks

~~~
AdieuToLogic
> I think this will glob unless you escape the asterisks.

The majority of times, this is the case. At least one exception is when the
shell pattern does not match one or more files in the directory which find(1)
is executed. However, this can be "surprising" so it's best practice to either
use escapes or ensure interpolation is disabled via single quotes (in Bourne
shell syntax).

> Also on my system (debian 8) I need to put the directory to search first...

FWIW, you can specify more than one directory if desired. The primaries will
be applied to the results of each.

~~~
wnoise
> The majority of times, this is the case. At least one exception is when the
> shell pattern does not match one or more files in the directory

Thankfully zsh has the NULLGLOB option which will do the right thing and
expand to an empty list, of the zero matching files.

------
ryenus

      cat hosts | xargs -I{} ssh root@{} hostname
    

glad to know this one :-)

    
    
      echo y | xargs -Ix echo x
    

how tricky!

~~~
jnpatel
I agree, this is one of my favorite tricks. I like to think of xargs as a
`map` function over stdin lines.

As the article mentions, especially useful when combined with the -P flag for
paralellism.

    
    
        cat urlpaths.txt | xargs -I{} -P wget domain.com/{}
    

Another handy trick, is to use `sh -c` or `bash -c` to include multiple
commands with xargs.

    
    
        cat dirs.txt | xargs -I{} sh -c 'cd {}; touch file;'

------
widdershins
Seems like a good introduction. I'm an amateur who's been using IDEs up until
now. I'm just starting to become dimly aware of the power at the command line,
and slowly learning in a haphazard way. This could be very helpful.

------
natch
Another one for obscure but useful: jot

# print 10 values from 1 to 10, with leading zeros:

for n in `jot -w "%04d" 10 1 10`; do echo $n; done

~~~
anc84
Just use Bash's builtin things:

for n in {0001..0010}; do echo ${n}; done

~~~
willthames
Or seq -f %04g 1 10

~~~
natch
Sure seq is OK, but jot does everything seq does and more, so I prefer jot.

# generate 10 random numbers between 1 and 1 million

jot -r 10 1 1000000

~~~
anc84
I meant to go all "just use coreutils, there is shuf available already, no
need for some third-party tool" but then I realised that jot is an integral
part of BSD. Rock on! :)

For us Linuxers: shuf -i 1-1000000 -n 10

------
joelthelion
No mention of autojump? :-p

~~~
ryenus
I googled about autojump, then found fasd and decided to go with it.

[https://github.com/clvv/fasd](https://github.com/clvv/fasd)

------
Wonnk13
pretty good writeup. Learning nohup was a life changing experience for me.

~~~
unhammer
there's also disown. It's a bash builtin, so you'll have to type "help disown"
("man disown" gets you nothing). E.g. to run touchegg and close your terminal,
keeping touchegg running:

    
    
       touchegg & disown; exit

~~~
scrollaway
I use an alias for it:

    
    
        function launch {
        	type $1 >/dev/null || { print "$1 not found" && return 1 }
        	$@ &>/dev/null &|
        }
        alias launch="launch "

~~~
unhammer
why the alias as well as the function?

~~~
scrollaway
[https://wiki.archlinux.org/index.php/Sudo#Passing_aliases](https://wiki.archlinux.org/index.php/Sudo#Passing_aliases)

~~~
unhammer
ah, thanks for that tip :-)

------
michaelvkpdx
I learned a dozen new things in the first 100 lines or so, that will save me
hours, and I've been living in bash for 20 years.

Thanks for this!

------
cbd1984
There's no reason to learn vi if you know Emacs. If you claim that Emacs isn't
installed everywhere, guess what: Neither is vi.

If you want an "installed everywhere" editor, learn ed. If you're willing to
take an editor with you (or otherwise make sure a specific editor is
everywhere you are), there's no reason it has to be vi.

~~~
kec
vi is a posix requirement, emacs is not. If the system you're working on has
ed, it'll have some version of vi or vim as well.

~~~
shabble
and not having to know ed is an excellent reason to learn vi :)

obCompulsoryEdJoke: [https://www.gnu.org/fun/jokes/ed-
msg.html](https://www.gnu.org/fun/jokes/ed-msg.html)

~~~
endgame
a

I learned ed for a joke and found myself actually liking some features so much
that I started porting them to emacs.

.

w

~~~
bch
I've used ed(1) to do complex(ish) programmatic edits to files that I think
would have been extremely painful otherwise. An interesting editor worth
spending at least a small amount of brainpower on.

------
mozumder
Man so I guess tcsh/csh lost the shell wars?

~~~
AdieuToLogic
Nah, just the hearts and minds.

------
cbd1984
There's no reason to learn vi.

~~~
cbd1984
Anyone considering using vi should be warned away by this practice of
"disagreement by downvoting". If they do it here, imagine what they would do
to a bug report!

------
Ardebou
Before that I was not so familiar with cmd. After that I was.

