31–40 of 47 posts
If you don't have this basic linux utility, you can use grep '^string' file.txt but there's a greater chance of having look installed than grep.
The interesting thing about look is that it uses binary search, so it is much faster.
Earlier quoted context omitted.
The interesting thing about look is that it uses binary search, so it is much faster.
Binary search is useless unless the file is sorted. Most often my files are not sorted, so egrep '^line' works just fine.
Earlier quoted context omitted.
A better one-line description would be "look(1): binary search for lines with a given prefix in a sorted file" Which tells you exactly what the pros/cons are compared to plain grep.
I created a 1.1G file with dictionary words and timed... % du -h a 1.1G a % time look 'dog' a | wc -l 53856 real 0m0.021s user 0m0.020s sys 0m0.003s % time grep '^dog' a | wc -l 53856 real 0m28.593s user 0m0.977s sys 0m2.223s Ok grep performed worse than what I expected (sort took a long time though).
If you don't have this basic linux utility, you can use grep '^string' file.txt but there's a greater chance of having look installed than grep.
As long as I have been using *nixes, I have never met a machine that didn't have grep. It was written by Ken Thompson himself in 1974, or 41 years ago, and first came out in Unix 4th edition.
If you don't have this basic linux utility, you can use grep '^string' file.txt but there's a greater chance of having look installed than grep.
The interesting thing about look is that it uses binary search, so it is much faster.
Earlier quoted context omitted.
The interesting thing about look is that it uses binary search, so it is much faster.
Binary search is only faster if access to the elements is constant-time, which is not true for a file with varying-length records (lines). Line 1000 (counting from 0) could be at offset 2000 if each line is a single character + newline, or it could be at offset 2000000 if each line is 999 characters and a newline, or somewhere in between.
I also think your constant time claim sounds too strong. You can eat a lot of end of line search time after the binary search and still beat a linear/regex search.
As someone else pointed out, look can also exit sooner.
Earlier quoted context omitted.
The interesting thing about look is that it uses binary search, so it is much faster.
Binary search is useless unless the file is sorted. Most often my files are not sorted, so egrep '^line' works just fine.
Earlier quoted context omitted.
The interesting thing about look is that it uses binary search, so it is much faster.
Binary search is only faster if access to the elements is constant-time, which is not true for a file with varying-length records (lines). Line 1000 (counting from 0) could be at offset 2000 if each line is a single character + newline, or it could be at offset 2000000 if each line is 999 characters and a newline, or somewhere in between.
Earlier quoted context omitted.
A better one-line description would be "look(1): binary search for lines with a given prefix in a sorted file" Which tells you exactly what the pros/cons are compared to plain grep.
I created a 1.1G file with dictionary words and timed... % du -h a 1.1G a % time look 'dog' a | wc -l 53856 real 0m0.021s user 0m0.020s sys 0m0.003s % time grep '^dog' a | wc -l 53856 real 0m28.593s user 0m0.977s sys 0m2.223s Ok grep performed worse than what I expected (sort took a long time though).
look -b a |wc -l => 1228
look -bf a |wc -l => 1228
You must sort the /usr/share/dict/words file according to ignore case for the option bf to work properly.
Edit: I was expecting
sort -f /usr/share/dict/words | look -bf a | wc -l to be 5985 but the result is 1228, don't know why.