bug report: Emacs notmuch-mode fails attachments with spaces

[Tomi Ollila]

On Wed, Feb 11 2015, Tomi Ollila <tomi.ollila at iki.fi> wrote:

> On Tue, Feb 10 2015, Nils Dagsson Moskopp <nils at dieweltistgarnichtso.net> wrote:
>
>> Tomi Ollila <tomi.ollila at iki.fi> writes:

>> It seems to me that all of the following are true in this case:
>>
>> 1. Emacs executes the user's default shell to start zathura.
>
> That's stupid! it should run /bin/sh.
>
> I looked into emacs-23.1/lisp/gnus/mm-decode.el and while I could not
> pinpoint the exact location where this shell command was invoked, I
> found some similar code where emacs variable `shell-file-name` was used
> (M-x describe-variable shell-file-name returns "/bin/zsh" for me).
>
> So, you could just test by (setq shell-file-name "/bin/sh") (or 
> just M-x set-variable shell-file-name /bin/sh in live emacs) and then
> test whether those pdf:s open right.
>
> we cannot do much how (mm in) emacs escapes those variables (and why it
> uses shell to execute that command line)...

... but we could let-bind shell-file-name...

>
> Tomi
>
>>
>> 2. For this, Emacs escapes the filename.
>>
>> 3. Emacs applies the wrong escaping to the filename. Note that single
>>    quotes are interoperable between shells, while backslashes are not.
>>
>> 4. The rc(1) shell splits on spaces, as it knows no backslash escaping.
>>
>> 5. The shell executes zathura with three arguments, all bogus filenames.
>>
>> I cannot pinpoint where all this is happening, but I would suggest to
>> just execve() zathura with a single unescaped filename as its argument.
>>
>> Greetings,
>> -- 
>> Nils Dagsson Moskopp // erlehmann