bug report: Emacs notmuch-mode fails attachments with spaces

bug report: Emacs notmuch-mode fails attachments with spaces

[Nils Dagsson Moskopp]

[-- Attachment #1: Type: text/plain, Size: 811 bytes --]

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


Greetings,
-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>

[-- Attachment #2: Type: application/pgp-signature, Size: 212 bytes --]

Re: bug report: Emacs notmuch-mode fails attachments with spaces

[Tomi Ollila]

On Mon, Feb 09 2015, Nils Dagsson Moskopp <nils@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

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 ;)


Tomi








>
>
> Greetings,
> -- 
> Nils Dagsson Moskopp // erlehmann
> <http://dieweltistgarnichtso.net>
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Re: bug report: Emacs notmuch-mode fails attachments with spaces

[David Bremner]

Tomi Ollila <tomi.ollila@iki.fi> writes:

> SO, there is 2 options:
>
> 1) mm executes save part correctly but not display part
>
> 2) there is (shell) wrapper program executing zathura which cannot handle
>    arguments with spaces (there is plenty of examples of this!)
>

For what it's worth, emacs-24.4 / notmuch-0.19+48 / Debian / zsh and
mupdf as a previewer, it ". v" worked ok on the examples I tried with
spaces in the file name of a pdf attachment.

Re: bug report: Emacs notmuch-mode fails attachments with spaces

[Nils Dagsson Moskopp]

[-- Attachment #1: Type: text/plain, Size: 3392 bytes --]

Tomi Ollila <tomi.ollila@iki.fi> writes:

> On Mon, Feb 09 2015, Nils Dagsson Moskopp <nils@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 ...>
--- 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>

[-- Attachment #2: Type: application/pgp-signature, Size: 212 bytes --]

Re: bug report: Emacs notmuch-mode fails attachments with spaces

[Nils Dagsson Moskopp]

[-- Attachment #1: Type: text/plain, Size: 760 bytes --]

David Bremner <david@tethera.net> writes:

> Tomi Ollila <tomi.ollila@iki.fi> writes:
>
>> SO, there is 2 options:
>>
>> 1) mm executes save part correctly but not display part
>>
>> 2) there is (shell) wrapper program executing zathura which cannot handle
>>    arguments with spaces (there is plenty of examples of this!)
>>
>
> For what it's worth, emacs-24.4 / notmuch-0.19+48 / Debian / zsh and
> mupdf as a previewer, it ". v" worked ok on the examples I tried with
> spaces in the file name of a pdf attachment.

It does not work here with Emacs 23.4.1 / notmuch-0.18.2-1 / Debian and
Dash. I am installing the emacs24 package now and will report back then.

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>

[-- Attachment #2: Type: application/pgp-signature, Size: 212 bytes --]

Re: bug report: Emacs notmuch-mode fails attachments with spaces

[David Edmondson]

On Tue, Feb 10 2015, Nils Dagsson Moskopp wrote:
> Tomi Ollila <tomi.ollila@iki.fi> writes:
>
>> On Mon, Feb 09 2015, Nils Dagsson Moskopp <nils@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@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Re: bug report: Emacs notmuch-mode fails attachments with spaces

[Tomi Ollila]

On Tue, Feb 10 2015, Nils Dagsson Moskopp <nils@dieweltistgarnichtso.net> wrote:

> Tomi Ollila <tomi.ollila@iki.fi> writes:
>
>> On Mon, Feb 09 2015, Nils Dagsson Moskopp <nils@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?

you could download emacs-el package or something....

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

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)...

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

Re: bug report: Emacs notmuch-mode fails attachments with spaces

[Tomi Ollila]

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

> On Tue, Feb 10 2015, Nils Dagsson Moskopp <nils@dieweltistgarnichtso.net> wrote:
>
>> Tomi Ollila <tomi.ollila@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

Re: bug report: Emacs notmuch-mode fails attachments with spaces

[David Bremner]

Tomi Ollila <tomi.ollila@iki.fi> writes:

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

If that seems needed, I think I'd rather push the bug upstream.

Re: bug report: Emacs notmuch-mode fails attachments with spaces

[Nils Dagsson Moskopp]

[-- Attachment #1: Type: text/plain, Size: 3123 bytes --]

David Edmondson <dme@dme.org> writes:

> On Tue, Feb 10 2015, Nils Dagsson Moskopp wrote:
>> Tomi Ollila <tomi.ollila@iki.fi> writes:
>>
>>> On Mon, Feb 09 2015, Nils Dagsson Moskopp <nils@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>

[-- Attachment #2: Type: application/pgp-signature, Size: 212 bytes --]