I want to find, say, 10 most common word in a text file. Firstly, solution should be optimized for keystrokes (in other words - my time). Secondly, for the performance. Here is what I have so far to get top 10:

cat test.txt | tr -c '[:alnum:]' '[\n*]' | uniq -c | sort -nr | head  -10
  6 k
  2 g
  2 e
  2 a
  1 r
  1 k22
  1 k
  1 f
  1 eeeeeeeeeeeeeeeeeeeee
  1 d

I could make a java, python etc. program where I store (word, numberOfOccurences) in a dictionary and sort the value or I could use MapReduce, but I optimize for keystrokes.

Are there any false positives? Is there a better way?

  • why would you put a -10 at the end ? :P
    – anu
    Jan 5, 2018 at 13:10

6 Answers 6


That's pretty much the most common way of finding "N most common things", except you're missing a sort, and you've got a gratuitious cat:

tr -c '[:alnum:]' '[\n*]' < test.txt | sort | uniq -ci | sort -nr | head  -10

If you don't put in a sort before the uniq -ci you'll probably get a lot of false singleton words. uniq only does unique runs of lines, not overall uniqueness.

You might want to use a trick, "stop words". If you're looking at English text (sorry, monolingual North American here), words like "of", "and", "the" almost always take the top two or three places. You probably want to eliminate them. The GNU Groff distribution has a file named eign in it which contains a pretty decent list of stop words. My Arch distro has /usr/share/groff/current/eign, but I think I've also seen /usr/share/dict/eign or /usr/dict/eign in old Unixes.

You can use stop words like this:

tr -c '[:alnum:]' '[\n*]' < test.txt |
fgrep -v -w -f -i /usr/share/groff/current/eign |
sort | uniq -ci | sort -nr | head  -10

My guess is that most human languages need similar "stop words" removed from meaningful word frequency counts, but I don't know where to suggest getting other languages stop words lists.

The -w flag on fgrep enables whole-word matching. This avoids false positives on words that merely contain short stop works, like "a" or "i". The -i flag on uniq and fgrep ignores case while comparing words.

  • 3
    Does cat add some significant performance overhead? I like the pipe syntax. What does the * in '[\n*]' do? Jun 24, 2012 at 1:04
  • 1
    If you like the "cat test.txt", then by all means use it. I've read an article someplace where Dennis Ritchie says that the "cat something | somethingelse" syntax is more widely used, and that the '< something' syntax was something of a mistake, since it's single purpose.
    – user732
    Jun 24, 2012 at 22:25
  • What if I want to find the most common directory name in a find output? That is, split words on / instead of whitespace characters and similar.
    – erb
    Feb 15, 2016 at 13:03
  • 1
    @erb - you would probably do something like: find somewhere optoins | tr '/' '\n' | sort | uniq -c | sort -k1.1nr | head -10
    – user732
    Feb 15, 2016 at 15:03
  • 1
    @erb - ask that as a question, not in a comment. You will have more room to frame your question, so as to get the answer you need. Give example input, and desired output. You might get some reputation points for asking a good question, and I will get points for giving a better answer than I can in a comment.
    – user732
    Feb 15, 2016 at 17:39

This works better with utf-8:

$ sed -e 's/\s/\n/g' < test.txt | sort | uniq -c | sort -nr | head  -10

Let's use AWK!

This function lists the frequency of each word occurring in the provided file in Descending order:

function wordfrequency() {
  awk '
     BEGIN { FS="[^a-zA-Z]+" } {
         for (i=1; i<=NF; i++) {
             word = tolower($i)
     END {
         for (w in words)
              printf("%3d %s\n", words[w], w)
     } ' | sort -rn

You can call it on your file like this:

$ cat your_file.txt | wordfrequency

and for the top 10 words:

$ cat your_file.txt | wordfrequency | head -10

Source: AWK-ward Ruby


This is a classic problem that got some resonance in 1986, when Donald Knuth implemented a fast solution with hash tries in an 8-pages-long program to illustrate his literate programming technique, while Doug McIlroy, the godfather of Unix pipes, responded with a one-liner, that was not as quick, but got the job done:

tr -cs A-Za-z '\n' | tr A-Z a-z | sort | uniq -c | sort -rn | sed 10q

Of course, McIlroy's solution has time complexity O(N log N), where N is a total number of words. There are much faster solutions. For example:

Here is a C++ implementation with the upper bound time complexity O((N + k) log k), typically – nearly linear.

Below is a fast Python implementation using hash dictionaries and heap with time complexity O(N + k log Q), where Q is a number of unique words:

import collections, re, sys

filename = sys.argv[1]
k = int(sys.argv[2]) if len(sys.argv)>2 else 10

text = open(filename).read()
counts = collections.Counter(re.findall('[a-z]+', text.lower()))
for i, w in counts.most_common(k):
    print(i, w)

Here is an extremely fast solution in Rust by Anders Kaseorg.

CPU time comparison (in seconds):

                                     bible32       bible256
Rust (prefix tree)                   0.632         5.284
C++ (prefix tree + heap)             4.838         38.587
Python (Counter)                     9.851         100.487
Sheharyar (AWK + sort)               30.071        251.301
McIlroy (tr + sort + uniq)           60.251        690.906


  • bible32 is Bible concatenated with itself 32 times (135 MB), bible256 – 256 times respectively (1.1 GB).
  • Python scripts's non-linear slow down is caused purely by the fact that it processes files completely in memory, so the overheads are getting bigger for huge files.
  • If there was a Unix tool that could construct a heap and pick n elements from top of the heap, the AWK solution could achieve near-linear time complexity, while currently it is O(N + Q log Q).

Let's use Haskell!

This is turning into a language war, isn't it?

import Data.List
import Data.Ord

main = interact $ (=<<) (\x -> show (length x) ++ " - " ++ head x ++ "\n")
                . sortBy (flip $ comparing length)
                . group . sort
                . words


cat input | wordfreq


cat input | wordfreq | head -10
  • a modified version ignoring case: pastebin.com/57T5B6BY Oct 24, 2017 at 6:08
  • Works much slower than classic sort | uniq -c | sort -nr. Jul 9, 2019 at 9:43
  • @AndriyMakukha The bottleneck is that strings are linked lists of characters in Haskell. We could get C-like speeds by switching to Text or ByteString instead, which is as simple as importing it qualified and prefixing the functions with the qualifier.
    – BlackCap
    Jul 11, 2019 at 23:31
  • pastebin.com/QtJjQwT9 significantly faster version, written for readability
    – BlackCap
    Jul 12, 2019 at 0:55

Something like this should work using python which is commonly available:

cat slowest-names.log | python -c 'import collections, sys; print collections.Counter(sys.stdin);'

This assumes word per line. If there are more, splitting should be easy as well.

  • python3 and nicer output cat README.md | python -c 'import collections, sys, pprint; pprint.pprint(collections.Counter(sys.stdin));' Aug 27, 2019 at 12:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .