Live data from Hacker News

Top Unix Command Line Utilities

blog.coldflake.com

11–20 of 65 posts

Re: Top Unix Command Line Utilities

#11
post #10

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

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

Re: Top Unix Command Line Utilities

#12
post #3

These obviously aren't related to 2012 at all. Some issues: - don't forget that /dev/random blocks - It's easier to use dd_rescue to track progress than to signal dd - Using dd to zero out a hard drive repeatedly doesn't increase security[1]. Using ATA secure erase does[2] - an alternative for summing file sizes is du -ch **/*.png [1] http://en.wikipedia.org/wiki/Data_erasure#Number_of_overwrit... [2] https://ata.wik…

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…

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.

Re: Top Unix Command Line Utilities

#14
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.

Re: Top Unix Command Line Utilities

#17
post #14

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 emacscli…

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

Re: Top Unix Command Line Utilities

#18
post #16

cat ~/.bash_history | cut -f1 -d' ' | sort | uniq -c | sort -rn | head -10 | cut -b9-

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

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

give me a break.

Re: Top Unix Command Line Utilities

#19
post #17
post #14

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 emacscli…

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

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.

Re: Top Unix Command Line Utilities

#20
post #16

Earlier quoted context omitted.

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

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

Hey calm down, I didn't mean to be agressive sorry if you felt my comment that way.

You can count scripts as commands (I did it in my other comment elsewhere on this page) but the way you do it you will miss a lot. For instance you won't count any "uniq", "sort", … that are almost exclusively used as filter and not in first command, you will also miss a lot of "less" and "grep" for instance.

Post reply on HN