🚀 go-pugleaf

Joachim Schrod wrote:
> newsspam5REMOVETHIS@robf.de wrote:
> > Joachim Schrod <jschrod@acm.org> writes:
> > > My vm-mime-external-content-types-alist has the entry
> > > ("application/pdf" "acroread")
> > >
> > > When an attachment name has spaces in it, acroread is called with
> > > several arguments instead of one. Anybody got a patch already for
> > > that? Then I won't have to look at the issue myself. ;-)
> >
> > Have you Googled?
> >
> > http://groups.google.com/groups?selm=400320B7.5060408%40yahoo.com
> > http://groups.google.com/groups?selm=86hdyoc6n9.fsf%40robf.deREMOVETHIS
>
> Yes, but obviously my search term was not good enough. This thread
> didn't appear on the first two pages. Thanks for the pointers, they
> remedy my problem.
> >
> > > Incidentially, that looks as if the external-content program is
> > > called via a shell. Anybody knows why that is done or if it can be
> > > avoided? That behaviour opens up issues of shell command
> > > insertions which would be more difficult if the program is called
> > > directly.
> >
> > It is called via 'start-process', which IMHO is not the shell.
>
> But then one wouldn't need the quoting that is introduced in the first
> posting you refered to, above. If one just passes the attachment name
> as argument to start-process, it wouldn't be split at white
> space. Anyhow, it works this way; perhaps I'll check for the shell
> call when I have more time.

Read the doc string for vm-mime-external-content-types-alist carefully:
a single string is interpreted as a shell COMMAND-LINE and multiple
strings are interepreted as PROGRAM ARG ARG ...

To prevent the shell from being invoked, change the entry to:
("application/pdf" "acroread" "%f")

-- 
Kevin