Top Unix Command Line Utilities

I think the only "secure" way to erase the contents of a hard drive is to repeatedly overwrite the disk surface with a mix of random/patterened data (like Darik's Boot & Nuke does).

Also, for those wondering about the blocking of /dev/random, it will restrict the number of bits you can copy using dd, but this won't be apparent unless you attempt to copy more bits from the entropy pools than there are available for random number generation. For more information, see this question on Super User: http://superuser.com/questions/520601/why-does-dd-only-copy-...

dsr_• 14 years ago

Secure erase depends on the technology of the drive and the prowess of your attacker.

If you fear the NSA seizing your disks, consider the tradeoffs of explosive disposal.

If you fear a technically-savvy reporter going through your trash bin, overwriting your disk three or four times with patterns will be fine. But it's probably faster to take a drill and make a couple of holes. Make sure you hit the platters.

If you are selling your old hardware and just don't want your unencrypted stuff to be recovered by a sixteen year old with no budget but lots of time, overwrite the disk once.

If you're trashing an SSD, make sure any patterns you use for overwriting are not compressed out of existence by the controller. Or pull off the controller and crunch it.

DanBC• 14 years ago

The ATA secure erase command is faster, and should be better than overwriting. Overwriting has potential for missing sectors marked as bad but Secure erase will get those.

Multiple over writes is pointless. There's the Gutmann stuff, but that's ancient and the 35 passes was for multiple drive controllers, if you didn't know what drive controller was being used.

But then sometimes you don't have to do what works, but what other people tell you. Thus, if you're working to a standard it doesn't matter if DOD specifications are actually more secure than a single secure erase, you do what the spec calls for. And if you have to persuade other people that the data is provably gone it's easiest to just grind the drives.

a3_nm2• 14 years ago

> It's easier to use dd_rescue to track progress than to signal dd

Why? I just use: watch pkill -USR1 dd

FuzzyDunlop• 14 years ago

You can also use Ctrl+T to get the status of a running command, instead of faffing about with pids and kill.

helper• 14 years ago

That doesn't work for me, but sending USR1 does.

kps2• 14 years ago

Linux still hasn't picked up 'stty kerninfo'.

visarga2• 14 years ago

My 2012 top, in order of usage:

joe, ls, cd, time, cdbdump, tail, more, cat, rm, grep, wc, apachectl restart, find, curl, chmod, history, mv, locate, cpan, apt-get, pwd

But the most useful one is a command line Perl utility I called "flt" that executes a block of perl code for each in the stdin.

cat file.txt | flt ' $line=~ s|\s+| |gsi; print $line."\n"; '

That would compact free spaces

find . | flt ' if (-f $line) { print (-s $line)."\n"; } '

This would print the size of all files in the current folder and subfolders.

So it works like awk, but with full Perl, no need to learn awk syntax. You can do conditionals, loops and whatnot. I write 30% of my one time throw away scripts directly in the command line.

EvilTerran• 14 years ago

Are you familiar with perl's -n and -p switches?

http://perldoc.perl.org/perlrun.html#*-n*

Those "flt" lines could be written

  perl -lpe 's|\s+| |gsi' file.txt
  find . | perl -ne 'if (-f) { print -s }'

(-l chomps the incoming newlines, and puts them back on the output)

Of course, "perl -ne" is longer than "flt", and I appreciate all this implicit use of $_ is not to everyone's tastes.

visarga2• 14 years ago

Yes, but I bundled slightly better syntactic sugar in my tool. It's the same, in essence.

cldwalker• 14 years ago

A more interesting set of commandline utilities to know - http://www.cyberciti.biz/open-source/best-terminal-applicati...

IamBren• 14 years ago

This list is definitely more interesting to me. I discovered a few of these already this year and have been using them a lot (mtr, pv, curl for inspecting headers) and several others that I know I'm going to start messing with immediately (siege, multitail).

Another VERY useful tool I didn't see on this list is iperf. From the Debian package description:

Iperf is a modern alternative for measuring TCP and UDP bandwidth performance, allowing the tuning of various parameters and characteristics.

Features:

* Measure bandwidth, packet loss, delay jitter

* Report MSS/MTU size and observed read sizes.

* Support for TCP window size via socket buffers.

* Multi-threaded. Client and server can have multiple simultaneous connections.

* Client can create UDP streams of specified bandwidth.

* Multicast and IPv6 capable.

* Options can be specified with K (kilo-) and M (mega-) suffices.

* Can run for specified time, rather than a set amount of data to transfer.

* Picks the best units for the size of data being reported.

* Server handles multiple connections.

* Print periodic, intermediate bandwidth, jitter, and loss reports at specified intervals.

* Server can be run as a daemon.

* Use representative streams to test out how link layer compression affects your achievable bandwidth.

I use iperf initially when I'm troubleshooting poor file server transfer speeds, for example. There's a pretty Java GUI too if you want that.

niggler2• 14 years ago

Where's the love for awk? It has been tucked away in a sub item but doesn't deserve first class status?

imglorp• 14 years ago

That whole "find -ls | awk" is wicked slow anyway; try wc and xargs...

  $ time find -ls | awk '{s += $7} END {print s}'
  15970582120

  real	0m27.721s
  user	0m1.256s
  sys	0m1.780s

  $ time find | xargs wc -c 2> /dev/null | tail -1
  604260969 total

  real	0m0.332s
  user	0m0.068s
  sys	0m0.204s

dbaupp2• 14 years ago

The standard disclaimer on find | xargs: you should use -print0 and -0 to avoid problems with files with whitespace in their names, i.e.

   $ find -print0 | xargs -0 wc -c 2> /dev/null | tail -1

(Also, many uses of find | xargs can be replaced with -exec cmd {} \; or -exec cmd {} +, e.g.

  $ find -exec wc -c {} + 2> /dev/null | tail -1

although this isn't much faster in this case.)

zxcdw2• 14 years ago

I am not familiar with awk, what's the 's+= $7'? What is the argument 2 passed to wc? Why is the produced output different? What am I missing here?

aidos• 14 years ago

You sure that's not because of memory swapping? Once warmed up the awk command is much faster for me.

Also, the results are different - though I'm too lazy to figure out why right now :)

coldgrnd4• 14 years ago

actually there is heaps of love for awk... so much actually that I'd rather spend a whole post on it than to "just" make it one item :)

niggler2• 14 years ago

Motivated by your list, I went through my history to pull some awk snowclones http://news.ycombinator.com/item?id=4989524

prostoalex• 14 years ago

2013 will be the year of awk on the desktop.

andrewcooke2• 14 years ago

p4bl05• 14 years ago

That's not enough, you need to split lines on "|" and ';' and before that after for's "do" and if's "then".

andrewcooke2• 14 years ago

sure, and search through your file system to find all scripts written this year, to include those too....

give me a break.

dbaupp2• 14 years ago

It's not too hard to do (a very basic) implementation of splitting on | and ;, e.g.

  sed 's/ *| */\n/g' ~/.bash_history | cut -f1 -d' ' | ...

(This fails on something like "echo 'a | b'" and doesn't split correctly on |& and || and doesn't split at all on &&.)

p4bl05• 14 years ago

I'm a heavy command line user (I don't have a graphical file explorer/manager for instance). Here is my top 42, in order of usage:

    ls, cd, git, ssh, make, e, cat, veille, rm,
    wpa_supplicant, grep, evince, mv, x, dhclient,
    cp, echo, todo, mplayer, scp, man, mkdir, ack,
    pdflatex, apt-get, apt-cache, sed, less, feh,
    racket, gcc, wget, xrandr, bg, svn, pmount,
    for, gpg, halt, ping, tail, top.

"e" is an alias for emacsclient ; "veille" is a script which toggles between "xset s 5" and "xset s default" ; "x" is an alias for "xinit" ; "todo" is a script which manage a text file which I use as a todo list.

"ls", "cd", and "git" are far more used than any other commands : 14808, 13256 and 10078 times respectively, against 3919 times for "ssh" which is just behind.

I obtained these data from my .bash_history. Here are the place of the commands that are listed in the article :

    "tr" is 76th
    "sort" is 66th
    "uniq" is 120th
    "split" is there only one time like many other command so its rank is not relevant
    Substitutions operations are what most "for" do so it is in my top 42. However see (1) below about the article.
    Files size are a mix of "ls" for individual file and "du" for multiple files, "du" is 65th
    "df" is 63rd
    "dd" is 473rd
    "zip" is 123rd (and funnily "gzip" is 122nd)
    I didn't use "hexdump"

(1) About the following line

    for i in *.mp4; do ffmpeg -i "$i" "${i/.mp4}.mp3"; done

I have two remarks. First, using the "-vn" of ffmpeg would accelerate the conversion by making ffmpeg ignore the video entirely. Second, substituting with '/' in the Bash expansion is not the right way to do that. "${i/.mp4}" would be "$i" without the first occurence of ".mp4". It is '%' that you want to use here.

fqsxr• 14 years ago

I wonder how large is your HISTFILESIZE, to get these accurate statistics?

p4bl05• 14 years ago

My .bash_history weights 1.7Mo (almost 100k lines). I set a very high HISTSIZE since I don't see any reason to lose this data.

coldgrnd4• 14 years ago

wow...that's quite some statistical data you gathered! I tried this myself using this command:

    cat ~/.bash_history | cut -f1 -d' ' | sort | uniq -c | sort -n -r

turns out my .bash_history is clipped at it's default size-limit (500 lines). So I'll change that to gather more data for next year. My results started with: 147 clang++ 77 ls 54 cd 15 gs 14 rake 13 vim ...

where gs is short for "git status" ...and thanks for the hint about the substitution! I updated it on my page.

dmckeon• 14 years ago

In a bash session (bash 2.05 or later):

  $ hash | sort -nr | less

shows usage counts and full paths of executed commands.

stiff3• 14 years ago

"for i in *.mp3" doesn't work with spaces and some other "special" characters in filenames, see here:

http://unix.stackexchange.com/questions/9496/looping-through...

decklin2• 14 years ago

The for loop works fine. Performing word splitting/wildcard expansion/etc on a variable will, well, split it into words/expand wildcards/etc, whether it was introduced by a for loop or not.

stiff3• 14 years ago

I am not sure I understand what you mean. Word-splitting is performed by the "for x in y" construct, using the IFS variable, so by default if you have a file called "foo bar.mp4" the command line from the article:

  for i in *.mp4; do ffmpeg -i "$i" "${i%.mp4}.mp3"; done

will result in executing:

  ffmpeg -i foo foo.mp3
  ffmpeg -i bar.mp4 bar.mp3

Which is obviously not what was meant. So it's a good habit to learn to loop over files in a directory in a different way.

Zash• 14 years ago

xxd is a pretty nice hexdump substitute that has a reverse mode of operation (-r), turning a hexdump into binary.

shabble• 14 years ago

From what I recall xxd is actually part of the vim distribution, so it's common, but not everywhere. An approximate standard (coreutils) alternative is `od -x' (although it doesn't include the ASCII readable char column at the right, which can be annoying)

bejar37• 14 years ago

Aaa

tomaac• 14 years ago

Combine sort and uniq is useless since sort has already -u flag.

etrain3• 14 years ago

sort | uniq -c | sort -n

is something I use all the time to get sorted frequency tables.

etrain3• 14 years ago

And, by the way, the two commands are something that could be done in O(n), rather than O(n*log(n)) - but this little procedure is so damn easy to write, that on relatively thin inputs that are less than 20m lines long, I usually just do this.

nieve• 14 years ago

Except for those cases where you want counts, only unique/only duplicate, skipping fields, doing case-insensitive duplicate detection, or only comparing a chunk of the line - all but the last two I've used and now that I've found those in the man page (GNU uniq) I can replace some silly shell hacks that I've used over the years. It's like saying that tail is pointless unless you're doing tail -f... you're missing the actual useful functionality due to presuming the tool only does what you've done with it in the past.

meaty• 14 years ago

So basically the same as in 1985?

etrain3• 14 years ago

Basically. And that's a good thing.

minhajuddin• 14 years ago

Not really a bash utility, but delegating to this script from vim has been a huge timesaver for long running scripts. For instance I can trigger my ruby specs from Vim without vim getting blocked. I wrote a blog post about it here: http://minhajuddin.com/2012/12/25/run-specs-tests-from-withi...

    #!/bin/bash
    #~/.scripts/runinbg
    #Author: Khaja Minhajuddin
    #Script to run a command in background redirecting the
    #STDERR and STDOUT to /tmp/runinbg.log in a background task

    echo "$(date +%Y-%m-%d:%H:%M:%S): started running $@" >> /tmp/runinbg.log
    cmd="$1"
    shift
    $cmd "$@" 1>> /tmp/runinbg.log 2>&1 &
    #comment out the above line and use the line below to get get a notification
    #when the test is complete
    #($cmd "$@" 1>> /tmp/runinbg.log 2>&1; notify-send --urgency=low -i "$([ $? = 0 ] && echo terminal || echo error)" "$rawcmd")&>/dev/null &

akurilin• 14 years ago

Does anybody know of great guides to master the majority of the useful CLI tools available on Unix and Linux? For me the challenge is that I don't even know I have some of these fantastic solutions readily available. I'd really benefit of knowing they're there in the first place instead of hacking a homebrew solution every time.

Learn Linux the Hard Way talks about them quite a bit, is that the go to guide in 2012 or can I do better?

sea6ear• 14 years ago

http://www.commandlinefu.com/commands/browse is a good resource to at least browse through for inspiration.

I also learned a lot from "The Linux Cookbook" (Second Edition) by Michael Stutz (this might be the first edition online: http://dsl.org/cookbook/cookbook_toc.html).

4ad2• 14 years ago

The second #6 example, the one with xargs, is wrong. Xargs(1) doesn't necessarily create a single du process, it might create several.

coldgrnd4• 14 years ago

I was wondering about that, but is it really wrong? From what I found in the "BSD General Commands Manual":

Any arguments specified on the command line are given to utility upon each invocation, followed by some number of the arguments read from the standard input of xargs. The utility is repeatedly executed until standard input is exhausted.

and

-P maxprocs Parallel mode: run at most maxprocs invocations of utility at once.

The way I interpret that is that you could run xargs in parallel mode, but by default the "utility is repeatedly executed" in the same process.

4ad2• 14 years ago

If the utility is repeatedly executed then by definition it can't be a single process.

cben• 14 years ago

Even in sequential mode, for a sufficiently long input xargs will invoke the command multiple times to comply with kernel limits on command line length.

Top Unix Command Line Utilities

Related Stories