From: Tomi Ollila <tomi.ollila@iki.fi>
To: Nils Dagsson Moskopp <nils@dieweltistgarnichtso.net>,
notmuch@notmuchmail.org
Subject: Re: bug report: Emacs notmuch-mode fails attachments with spaces
Date: Wed, 11 Feb 2015 14:28:03 +0200 [thread overview]
Message-ID: <m24mqs63ak.fsf@guru.guru-group.fi> (raw)
In-Reply-To: <8761b9pu11.fsf@dieweltistgarnichtso.net>
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
next prev parent reply other threads:[~2015-02-11 12:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-09 21:45 bug report: Emacs notmuch-mode fails attachments with spaces Nils Dagsson Moskopp
2015-02-10 7:06 ` Tomi Ollila
2015-02-10 11:55 ` David Bremner
2015-02-10 17:19 ` Nils Dagsson Moskopp
2015-02-10 17:15 ` Nils Dagsson Moskopp
2015-02-10 17:38 ` David Edmondson
2015-05-31 0:42 ` Nils Dagsson Moskopp
2015-02-11 12:28 ` Tomi Ollila [this message]
2015-02-20 9:25 ` Tomi Ollila
2015-02-23 9:51 ` David Bremner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://notmuchmail.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m24mqs63ak.fsf@guru.guru-group.fi \
--to=tomi.ollila@iki.fi \
--cc=nils@dieweltistgarnichtso.net \
--cc=notmuch@notmuchmail.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).