bug report: Emacs notmuch-mode fails attachments with spaces

[David Edmondson]

On Tue, Feb 10 2015, Nils Dagsson Moskopp wrote:
> Tomi Ollila <tomi.ollila at iki.fi> writes:
>
>> On Mon, Feb 09 2015, Nils Dagsson Moskopp <nils at dieweltistgarnichtso.net> wrote:
>>
>>> Dear notmuch developers,
>>>
>>>
>>> I use notmuch-mode for GNU Emacs for managing my email.
>>>
>>> I think I have found a bug in notmuch-mode: If I do “.-v” on the line “[
>>> 2015 _ Richtlinien.pdf: application/pdf ]”, then notmuch will open three
>>> windows of zathura (the PDF viewer I use).
>>>
>>> It seems to me that someone here either forgot quoting or decided to
>>> split filenames on spaces. I suggest that “2015 _ Richtlinien.pdf:
>>> application/pdf” should be quoted in notmuch-show-view-part.
>>>
>>> Note that saving attachment (“.-s”, notmuch-show-save-part) generally
>>> works even if the attachment file names have spaces. In case it matters,
>>> I normally use the rc(1) shell in Debian <http://tobold.org/article/rc>.
>>
>> This code handles the saving and displaying in question (quick look hop i
>> am right :)
>>
>>    2282 (defun notmuch-show-save-part ()
>>    2283   "Save the MIME part containing point to a file."
>>    2284   (interactive)
>>    2285   (notmuch-show-apply-to-current-part-handle #'mm-save-part))
>>    2286 
>>    2287 (defun notmuch-show-view-part ()
>>    2288   "View the MIME part containing point in an external viewer."
>>    2289   (interactive)
>>    2290   ;; Set mm-inlined-types to nil to force an external viewer
>>    2291   (let ((mm-inlined-types nil))
>>    2292     (notmuch-show-apply-to-current-part-handle #'mm-display-part)))
>>
>> SO, there is 2 options:
>>
>> 1) mm executes save part correctly but not display part
>
> It seems I cannot investigate this with my knowledge, as “M-x
> find-function RET mm-display-part” gives “Can't find library
> /usr/share/emacs/23.4/lisp/gnus/mm-decode.el”. Any ideas?
>
>> 2) there is (shell) wrapper program executing zathura which cannot handle
>>    arguments with spaces (there is plenty of examples of this!)
>>
>>
>> You could try to check how th external processes are executed by executing:
>>
>> strace -f -e trace=process emacs -f notmuch
>>
>> (emacs on X is preferable in this case ;)
>
> Thank you for that suggestion. It seems that there does happen both some
> (wrong) escaping and splitting at spaces. I can see the following trace:
>
> --- snib ---
> execve("/usr/bin/zathura", ["/usr/bin/zathura", "/tmp/emm.23178ut2/2015\\", "_\\", "Richtlinien.pdf"] [/* 51 vars */]) = 0
> --- snab ---
>
> Somewhat unusually, it is preceeded by an invocation of the shell:
>
> --- sneb ---
> execve("/usr/bin/rc", ["/usr/bin/rc", "-c", "/usr/bin/zathura /tmp/emm.23178u"...], [/* 51 vars */] <unfinished ...>

It would be useful to see the rest of this string ^^. Can you persuade
strace to show more please?

> --- snob ---
>
> 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.
>
> 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
> <http://dieweltistgarnichtso.net>
> _______________________________________________
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch