Re: Mailcap question: should %s be quoted?
On Wed, Apr 06, 2005 at 01:53:53PM -0700, Bill Moseley wrote:
> This is something that catches me once in a while -- mostly when using
> mutt. And in fact, I discussed this once on the Mutt list[1], last
> month and the recommendation was to NOT use quotes around the %s in
> the mailcap file.
>
> What's the mailcap specification? Should there be quotes or not?
Good question. I couldn't find any clear statement in RFC 1524[1]
which would answer this question, but all the examples given in that
RFC are without quotes. So, one might conclude it's in the
responsibility of the application making use of the mailcap file to
appropriately quote %-parameters. But it isn't clear at all...
There's a BNF-like (RFC 822) grammar describing the syntax of a mailcap
entry. However, it's rather unspecific about expansion parameters like
%s. Not even the % gets any special mention in the grammar -- it just
says
...
view-command = mtext
mtext = *mchar
mchar = schar / qchar
schar = * <any CHAR except ";","\", and CTLS>
qchar = "\" CHAR ; may quote any char
...
and then in a comment: 'Note also that while the definition of "schar"
includes the percent sign, "%", this character has a special meaning in
at least the UNIX semantics, ...' -- thereby conveniently evading the
issue by shifting it from syntax to "semantics"... ;) Unfortunately,
the description of those sematics in the appendix isn't clear either.
Debian's default mailcap comes with all %s's single quoted -- maybe in
an attempt to prevent possible security issues with other applications
not handling %s like mutt does. OTOH, if mutt puts its own pair of
single quotes around the interpolated string (like the thread you
started on the mutt list seems to indicate), things do end up as
''some value'', which kind of defeats the original purpose...[2]
Trying the empirical approach, I briefly checked how other distros and
conventional Unixes handle this in their default mailcap file (this is
in no way exhaustive or representative, though). The summarized
result: mostly no quotes at all, occasionally using double quotes
around %s.
FWIW, with my version of mutt (1.4.2.1i; with config setting
mailcap_sanitize=yes), when viewing MIME attachments, I've so far never
encountered this problem, as mutt seems to create a tempfile, with
spaces and all other unsafe chars replaced by underscores, thereby
simply circumventing this problem in the first place. I've just
verified it passes something like /home/almut/.mutt/tmp/test_doc.pdf
for %s, even though the original name (as shown in the attachment
listing) was "test doc.pdf".
But apparently, you're invoking mutt's mailcap functionality from
some other context...(?) and it's me not getting it... :)
Almut
[1] http://www.faqs.org/rfcs/rfc1524.html
Not sure whether that's the one and only RFC touching that issue.
(I simply took the number from mutt's filename rfc1524.c, which is the
source that takes care of most related stuff.)
[2] a quick check shows that the shell (bash) passes this as two args:
$ perl -e 'print join ":", @ARGV' ''some value''
some:value
Reply to: