Tag Archives: shell

losing locate

As much as MacOS’ Spotlight is an integral and indispensable part of my interaction with my laptop, a part of me still begrudges the “gratuitous” CPU and disk utilisation which is of course a necessary part of its operation.

However as a hardened Linux user unprepared to do without the luxury of the locate database, my inner resource miser was further upset on discovering that these databases were not shared, and with even more irritation enabled the periodic updatedb cron job, as was suggested by locate itself.

Whether it was SSD envy, a nagging sense of a job half-done or sheer procrastination I’m not sure, but last week I felt compelled to do away with the needless platter-spinning and found the answer far too quickly, in the form of the Spotlight shell utility mdfind.

One alias later:

alias locate="mdfind -name"

and I was able to destroy the locate database, and discontinue its indexing:

launchctl stop /System/Library/LaunchDaemons/com.apple.locate.plist
launchctl unload -w /System/Library/LaunchDaemons/com.apple.locate.plist

whew!

Some obligatory qualifications…

This applies largely to OS X 10.6, Snow Leopard. Leopard’s arrangement is slightly different, and I know nothing about earlier versions… And no, it doesn’t support all of locate’s arguments, but I rarely used them (apart from -i) anyway (and don’t have any case-sensitive, indexed filesystems on the mac right now). man mdfind provides workarounds for many of the more unusual uses of locate, and grep provides the rest…

something I didn’t know about mailcap

For a few weeks I’ve been idly wondering why I’ve been unable to get alpine to take advantage of the syntax-highlighted goodness of vim, when viewing attached patches. Having just won another small victory against my own ignorance, I thought it best to share.

Like any sensible mail client, alpine chooses viewers for attached files using lookups of the system mailcap files, /etc/mailcap and ~/.mailcap. Enabling plain-text viewing in vim should be as simple as assigning vim to the appropriate type(s) in ~/.mailcap (and, for some types, unchecking the alpine Show Plain Text Internally preference).

However, attempts to open plain-text files (in this case specifically text/x-patch) in the multi-talented vim editor failed: alpine simply returned a “finished” status, as if viewing had been successful. My suspicion was confirmed when I redirected vim’s ouptut (hidden by alpine) to a file:

Vim: Warning: Output is not to a terminal
Vim: Warning: Input is not from a terminal

The latter message was well known to me; it’s usually triggered by my forgetting to affix the “stdin hyphen” whilst piping input to vim.

The problem is that both vim and alpine require control of the terminal to function; vim does not simply return beautifully ANSI-escaped coloured text for later display. Attempts to somehow force alpine to relinquish control of the terminal, or for vim to take it, failed until I discovered the secret amongst mailcap’s flags, as described by the manual:

    copiousoutput
        This flag should be given whenever the interpreter is
        capable of producing more than a few lines of output
        on stdout, and does no interaction with the user. [...]

I’d seen this, but for some reason had always assumed ‘copiousoutput’ to be some sort of magic external pager, with no connection to the mailcap system. Reading on, the solution was clear:

    needsterminal
        If this flag is given, the named interpreter needs to
        interact with the user on a terminal. [...]

So, a few amendments to ~/.mailcap later:

  Text/X-Patch;    /usr/bin/vim -R -- '%s'; needsterminal

and alpine had gained magical powers to invoke terminal-based viewers. There’s more to this; in particular the ‘edit=‘ and ‘compose=‘ fields, not to mention print support. But that’s enough to get basic viewing in vim.

+1 for reading the manual. -1 for not reading it before embarking on terminal manipulation…