--- /dev/null
+Return-Path: <tomi.ollila@iki.fi>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id 4BD22431FBD\r
+ for <notmuch@notmuchmail.org>; Wed, 11 Feb 2015 04:28:37 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 2.438\r
+X-Spam-Level: **\r
+X-Spam-Status: No, score=2.438 tagged_above=-999 required=5\r
+ tests=[DNS_FROM_AHBL_RHSBL=2.438] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id CNpfQI4VJD81 for <notmuch@notmuchmail.org>;\r
+ Wed, 11 Feb 2015 04:28:31 -0800 (PST)\r
+Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34])\r
+ by olra.theworths.org (Postfix) with ESMTP id 569B5431FB6\r
+ for <notmuch@notmuchmail.org>; Wed, 11 Feb 2015 04:28:31 -0800 (PST)\r
+Received: from guru.guru-group.fi (localhost [IPv6:::1])\r
+ by guru.guru-group.fi (Postfix) with ESMTP id 3A40D100086;\r
+ Wed, 11 Feb 2015 14:28:04 +0200 (EET)\r
+From: Tomi Ollila <tomi.ollila@iki.fi>\r
+To: Nils Dagsson Moskopp <nils@dieweltistgarnichtso.net>,\r
+ notmuch@notmuchmail.org\r
+Subject: Re: bug report: Emacs notmuch-mode fails attachments with spaces\r
+In-Reply-To: <8761b9pu11.fsf@dieweltistgarnichtso.net>\r
+References: <87twyurc78.fsf@dieweltistgarnichtso.net>\r
+ <m24mqu455x.fsf@guru.guru-group.fi>\r
+ <8761b9pu11.fsf@dieweltistgarnichtso.net>\r
+User-Agent: Notmuch/0.19+53~gb45d2f9 (http://notmuchmail.org) Emacs/24.3.1\r
+ (x86_64-unknown-linux-gnu)\r
+X-Face: HhBM'cA~<r"^Xv\KRN0P{vn'Y"Kd;zg_y3S[4)KSN~s?O\"QPoL\r
+ $[Xv_BD:i/F$WiEWax}R(MPS`^UaptOGD`*/=@\1lKoVa9tnrg0TW?"r7aRtgk[F\r
+ !)g;OY^,BjTbr)Np:%c_o'jj,Z\r
+Date: Wed, 11 Feb 2015 14:28:03 +0200\r
+Message-ID: <m24mqs63ak.fsf@guru.guru-group.fi>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=utf-8\r
+Content-Transfer-Encoding: quoted-printable\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Wed, 11 Feb 2015 12:28:37 -0000\r
+\r
+On Tue, Feb 10 2015, Nils Dagsson Moskopp <nils@dieweltistgarnichtso.net> w=\r
+rote:\r
+\r
+> Tomi Ollila <tomi.ollila@iki.fi> writes:\r
+>\r
+>> On Mon, Feb 09 2015, Nils Dagsson Moskopp <nils@dieweltistgarnichtso.net=\r
+> wrote:\r
+>>\r
+>>> Dear notmuch developers,\r
+>>>\r
+>>>\r
+>>> I use notmuch-mode for GNU Emacs for managing my email.\r
+>>>\r
+>>> I think I have found a bug in notmuch-mode: If I do =E2=80=9C.-v=E2=80=\r
+=9D on the line =E2=80=9C[\r
+>>> 2015 _ Richtlinien.pdf: application/pdf ]=E2=80=9D, then notmuch will o=\r
+pen three\r
+>>> windows of zathura (the PDF viewer I use).\r
+>>>\r
+>>> It seems to me that someone here either forgot quoting or decided to\r
+>>> split filenames on spaces. I suggest that =E2=80=9C2015 _ Richtlinien.p=\r
+df:\r
+>>> application/pdf=E2=80=9D should be quoted in notmuch-show-view-part.\r
+>>>\r
+>>> Note that saving attachment (=E2=80=9C.-s=E2=80=9D, notmuch-show-save-p=\r
+art) generally\r
+>>> works even if the attachment file names have spaces. In case it matters,\r
+>>> I normally use the rc(1) shell in Debian <http://tobold.org/article/rc>.\r
+>>\r
+>> This code handles the saving and displaying in question (quick look hop i\r
+>> am right :)\r
+>>\r
+>> 2282 (defun notmuch-show-save-part ()\r
+>> 2283 "Save the MIME part containing point to a file."\r
+>> 2284 (interactive)\r
+>> 2285 (notmuch-show-apply-to-current-part-handle #'mm-save-part))\r
+>> 2286=20\r
+>> 2287 (defun notmuch-show-view-part ()\r
+>> 2288 "View the MIME part containing point in an external viewer."\r
+>> 2289 (interactive)\r
+>> 2290 ;; Set mm-inlined-types to nil to force an external viewer\r
+>> 2291 (let ((mm-inlined-types nil))\r
+>> 2292 (notmuch-show-apply-to-current-part-handle #'mm-display-part=\r
+)))\r
+>>\r
+>> SO, there is 2 options:\r
+>>\r
+>> 1) mm executes save part correctly but not display part\r
+>\r
+> It seems I cannot investigate this with my knowledge, as =E2=80=9CM-x\r
+> find-function RET mm-display-part=E2=80=9D gives =E2=80=9CCan't find libr=\r
+ary\r
+> /usr/share/emacs/23.4/lisp/gnus/mm-decode.el=E2=80=9D. Any ideas?\r
+\r
+you could download emacs-el package or something....\r
+\r
+>\r
+>> 2) there is (shell) wrapper program executing zathura which cannot handle\r
+>> arguments with spaces (there is plenty of examples of this!)\r
+>>\r
+>>\r
+>> You could try to check how th external processes are executed by executi=\r
+ng:\r
+>>\r
+>> strace -f -e trace=3Dprocess emacs -f notmuch\r
+>>\r
+>> (emacs on X is preferable in this case ;)\r
+>\r
+> Thank you for that suggestion. It seems that there does happen both some\r
+> (wrong) escaping and splitting at spaces. I can see the following trace:\r
+>\r
+> --- snib ---\r
+> execve("/usr/bin/zathura", ["/usr/bin/zathura", "/tmp/emm.23178ut2/2015\\=\r
+", "_\\", "Richtlinien.pdf"] [/* 51 vars */]) =3D 0\r
+> --- snab ---\r
+>\r
+> Somewhat unusually, it is preceeded by an invocation of the shell:\r
+>\r
+> --- sneb ---\r
+> execve("/usr/bin/rc", ["/usr/bin/rc", "-c", "/usr/bin/zathura /tmp/emm.23=\r
+178u"...], [/* 51 vars */] <unfinished ...>\r
+> --- snob ---\r
+>\r
+> It seems to me that all of the following are true in this case:\r
+>\r
+> 1. Emacs executes the user's default shell to start zathura.\r
+\r
+That's stupid! it should run /bin/sh.\r
+\r
+I looked into emacs-23.1/lisp/gnus/mm-decode.el and while I could not\r
+pinpoint the exact location where this shell command was invoked, I\r
+found some similar code where emacs variable `shell-file-name` was used\r
+(M-x describe-variable shell-file-name returns "/bin/zsh" for me).\r
+\r
+So, you could just test by (setq shell-file-name "/bin/sh") (or=20\r
+just M-x set-variable shell-file-name /bin/sh in live emacs) and then\r
+test whether those pdf:s open right.\r
+\r
+we cannot do much how (mm in) emacs escapes those variables (and why it\r
+uses shell to execute that command line)...\r
+\r
+Tomi\r
+\r
+>\r
+> 2. For this, Emacs escapes the filename.\r
+>\r
+> 3. Emacs applies the wrong escaping to the filename. Note that single\r
+> quotes are interoperable between shells, while backslashes are not.\r
+>\r
+> 4. The rc(1) shell splits on spaces, as it knows no backslash escaping.\r
+>\r
+> 5. The shell executes zathura with three arguments, all bogus filenames.\r
+>\r
+> I cannot pinpoint where all this is happening, but I would suggest to\r
+> just execve() zathura with a single unescaped filename as its argument.\r
+>\r
+> Greetings,\r
+> --=20\r
+> Nils Dagsson Moskopp // erlehmann\r
+> <http://dieweltistgarnichtso.net>\r
+> _______________________________________________\r
+> notmuch mailing list\r
+> notmuch@notmuchmail.org\r
+> http://notmuchmail.org/mailman/listinfo/notmuch\r
projects / notmuch-archives.git / commitdiff