bug report: Emacs notmuch-mode fails attachments with spaces

[Nils Dagsson Moskopp]

David Edmondson <dme at dme.org> writes:

> 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?

I have no idea how. Do you?

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 212 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20150531/d0502569/attachment.sig>