On Sunday, June 17 at 10:06 PM, quoth Vincent Lefevre:
image/*; open %s; copiousoutput; nametemplate=%s.jpg text/html; elinks -dump -force-html %s; needsterminal; copiousoutput; application/pdf; open %s; copiousoutput; nametemplate=%s.pdf application/msword; open %s; copiousoutput; nametemplate=%s.doc application/excel; open %s; copiousoutput; nametemplate=%s.xlsBefore giving rules, perhaps you should make sure that they really work everywhere. I can tell you that this doesn't work on my machine, at least for PDF. You have a race condition here: the "open" command can return before the application (here, Preview) loads the file.
While you're lecturing me, maybe you can read what I wrote. There's important details there that obviously escaped your notice. The fact that 'copiousoutput' is in the 'open' lines forces mutt to leave the file there (it assumes that the command will produce output on stdout, and thus brings up a pager to view it, and so waits to delete the file until I tell it to exit the pager). Thus, there is no race condition, and it works correctly on all machines no matter how fast they are. The fact that you need to press q is a little annoying, but is hardly the equivalent of requiring coding.
You can even check my facts in the mutt source. Mutt will only unlink the file after having done a mutt_do_pager (which doesn't return until the pager exits).
The fact that my machine is a fast bi-processor machine can have an impact on the probability of failure. But I suggest that you try that on such a machine (if you can) with Preview already loaded.
Can you stick your nose any further up in the air about your fancy computer?
Another point is that the "open" command is under-specified (and doesn't always use the extension to determine the filetype). So, using "open" without more checking concerning what the file really contains to make sure the wanted application is launched is a bit weak on the security side.
It's only weak on the security side if an attacker can convince me to open a file I do not recognize and did not request. I'm no lame Outlook Express user, this is significantly more difficult than you'd imagine.
I also need a mailcap that works on various machines, where the current environment is an X11 one or not (hence the test of the DISPLAY environment variable).
Fair enough, but that's not the general case, and so has no bearing on the claim that you need to write code just to use mailcap on MacOS X.
I don't see why type lynx &> /dev/null isn't regarded as code while vi "$@"; true would be regarded as code.
For that matter, why isn't
vi foo.txt
considered code? Or better still, why aren't *all* mailcap entries
considered code? It's a fuzzy line. I would say that the latter of
your examples requires more detailed knowledge of your shell semantics
than the former (and is less portable). But is that a good universal
definition? No.
~Kyle --America will never be destroyed from the outside. If we falter and lose our freedoms, it will be because we destroyed ourselves.
-- Abraham Lincoln
Attachment:
pgpo4cURGpY1B.pgp
Description: PGP signature