From bf57dc6ecd01329c03a154986df639e2711582bd Mon Sep 17 00:00:00 2001 From: Tomi Ollila Date: Wed, 11 Feb 2015 14:28:03 +0200 Subject: [PATCH] Re: bug report: Emacs notmuch-mode fails attachments with spaces --- e4/9ab3d63d9dc191028848fd48266a6346ce9c4e | 178 ++++++++++++++++++++++ 1 file changed, 178 insertions(+) create mode 100644 e4/9ab3d63d9dc191028848fd48266a6346ce9c4e diff --git a/e4/9ab3d63d9dc191028848fd48266a6346ce9c4e b/e4/9ab3d63d9dc191028848fd48266a6346ce9c4e new file mode 100644 index 000000000..9b7d25ed5 --- /dev/null +++ b/e4/9ab3d63d9dc191028848fd48266a6346ce9c4e @@ -0,0 +1,178 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 4BD22431FBD + for ; Wed, 11 Feb 2015 04:28:37 -0800 (PST) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: 2.438 +X-Spam-Level: ** +X-Spam-Status: No, score=2.438 tagged_above=-999 required=5 + tests=[DNS_FROM_AHBL_RHSBL=2.438] autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id CNpfQI4VJD81 for ; + Wed, 11 Feb 2015 04:28:31 -0800 (PST) +Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34]) + by olra.theworths.org (Postfix) with ESMTP id 569B5431FB6 + for ; Wed, 11 Feb 2015 04:28:31 -0800 (PST) +Received: from guru.guru-group.fi (localhost [IPv6:::1]) + by guru.guru-group.fi (Postfix) with ESMTP id 3A40D100086; + Wed, 11 Feb 2015 14:28:04 +0200 (EET) +From: Tomi Ollila +To: Nils Dagsson Moskopp , + notmuch@notmuchmail.org +Subject: Re: bug report: Emacs notmuch-mode fails attachments with spaces +In-Reply-To: <8761b9pu11.fsf@dieweltistgarnichtso.net> +References: <87twyurc78.fsf@dieweltistgarnichtso.net> + + <8761b9pu11.fsf@dieweltistgarnichtso.net> +User-Agent: Notmuch/0.19+53~gb45d2f9 (http://notmuchmail.org) Emacs/24.3.1 + (x86_64-unknown-linux-gnu) +X-Face: HhBM'cA~ +MIME-Version: 1.0 +Content-Type: text/plain; charset=utf-8 +Content-Transfer-Encoding: quoted-printable +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Wed, 11 Feb 2015 12:28:37 -0000 + +On Tue, Feb 10 2015, Nils Dagsson Moskopp w= +rote: + +> Tomi Ollila writes: +> +>> On Mon, Feb 09 2015, Nils Dagsson Moskopp 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 =E2=80=9C.-v=E2=80= +=9D on the line =E2=80=9C[ +>>> 2015 _ Richtlinien.pdf: application/pdf ]=E2=80=9D, then notmuch will o= +pen 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 =E2=80=9C2015 _ Richtlinien.p= +df: +>>> application/pdf=E2=80=9D should be quoted in notmuch-show-view-part. +>>> +>>> Note that saving attachment (=E2=80=9C.-s=E2=80=9D, notmuch-show-save-p= +art) generally +>>> works even if the attachment file names have spaces. In case it matters, +>>> I normally use the rc(1) shell in Debian . +>> +>> 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=20 +>> 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 =E2=80=9CM-x +> find-function RET mm-display-part=E2=80=9D gives =E2=80=9CCan't find libr= +ary +> /usr/share/emacs/23.4/lisp/gnus/mm-decode.el=E2=80=9D. 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 executi= +ng: +>> +>> strace -f -e trace=3Dprocess 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 */]) =3D 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.23= +178u"...], [/* 51 vars */] +> --- 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=20 +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, +> --=20 +> Nils Dagsson Moskopp // erlehmann +> +> _______________________________________________ +> notmuch mailing list +> notmuch@notmuchmail.org +> http://notmuchmail.org/mailman/listinfo/notmuch -- 2.26.2