| Date: | 26 January 2011 |
|---|---|
| Tags: | computing, python |
Note that as of early 2013, I have switched to using ag, the fabulous Silver Searcher. While grin was fun, it was slower and does not support a per-project file like .agignore which is essential to keeping single-line minified JavaScript files out of my search results.
I want to admit how much I am enjoying the grin search tool that lets you use Python regular expressions in recursive searches across your filesystem, automatically ignoring directories like .hg and files with extensions like .pyc and .jpg.
Over the years I had already built a stable full of shell functions for doing grep(1) and find(1) in various combinations, and my functions even defaulted to using pcregrep(1) when available because Perl-style REs (which have nearly the same format used by Python) seem to require so many fewer backslashes for common cases. It hardly seemed worth the effort to move to another tool — and the grin output format seemed glarish and offensive at first glance, not at all like the austere output of traditional grep:
$ pip install grin $ cd Python-3.2b2 $ grin autoGIL ./Doc/whatsnew/2.6.rst: 3167 : :mod:`autoGIL`, ./Misc/HISTORY: 5577 : - There's a new module called "autoGIL", which
But I forced myself to try using it again a few weeks later, and when actually doing real work I could not help but notice that the results were far easier for my eyes to scan than grep output. This is an important point: so often, the issue of whether something looks like it will be easy to read is a quite different matter than whether it is actually difficult to read the moment you stop looking at it and start trying to look through it to see your data! Now I can clearly see where the output from one file ends and the next begins — which traditionally is quite difficult if you are looking through a series of files with very similar names. Long file paths no longer push matching lines to the right, splitting them across the right edge of my standard 80-column terminal window. In fact, one of my first objections to its layout had been the line consumed by each stand-alone file name; but in practice, I found, far more lines are gained because of the matches that are not split across the right edge.
You can run grin against individual files or directories by naming them on the command line; adjust the set of files to which it pays attention; and even revert its output to a traditional file:line format if you want to pass the output to another program. You can, in other words, ask it to behave more like traditional grep. But its default behavior, I gradually realized after running it several hundred times, is by far the most common way that I had been using grep anyway — to search the source files beneath my working directory for a pattern.
The author, Robert Kern, has answered emails promptly and was happy to accept a few patches. I now have a shell script that I run whenever I set up a new Unix account that builds a virtual environment, includes its bin directory in my PATH, and installs grin as one of the most important Python tools that I need always at my fingertips. Try it out!