From: David Edmondson Date: Tue, 10 Feb 2015 17:38:41 +0000 (+0000) Subject: Re: bug report: Emacs notmuch-mode fails attachments with spaces X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=b9f734336d828a6f9ab12ad8db6474e42f2010ba;p=notmuch-archives.git Re: bug report: Emacs notmuch-mode fails attachments with spaces --- diff --git a/75/061654d782faadd5b56725598d1551470ceb15 b/75/061654d782faadd5b56725598d1551470ceb15 new file mode 100644 index 000000000..9cf87afc3 --- /dev/null +++ b/75/061654d782faadd5b56725598d1551470ceb15 @@ -0,0 +1,182 @@ +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 D5990431E64 + for ; Tue, 10 Feb 2015 09:38:49 -0800 (PST) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: 1.739 +X-Spam-Level: * +X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 + tests=[DNS_FROM_AHBL_RHSBL=2.438, RCVD_IN_DNSWL_LOW=-0.7, + UNPARSEABLE_RELAY=0.001] 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 mNoq5yYplWuG for ; + Tue, 10 Feb 2015 09:38:47 -0800 (PST) +Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com + [209.85.212.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id BD27B431FC7 + for ; Tue, 10 Feb 2015 09:38:46 -0800 (PST) +Received: by mail-wi0-f173.google.com with SMTP id bs8so14155671wib.0 + for ; Tue, 10 Feb 2015 09:38:45 -0800 (PST) +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:to:subject:in-reply-to:references:user-agent + :from:date:message-id:mime-version:content-type + :content-transfer-encoding; + bh=x7uUJZQCje48JIXm+SDpdTYdJwEwLxcwNcJ5YIvUBcU=; + b=Kd43emnZ9evyDGF8jmJvgJxWbNj9+pKVs+SkP2VA/BvQ/he38Awuf/PyO+Qulj5wrk + z2MzO87DeahEc9v9VSnIbPvgcA1VwtHdb5zPiftGndoMzMmzdgxNjKHVZP8RISBXVFOn + TYm/y9pGume8oqYjEo0S2o43G2y/nBSkCM3+k9NeSvd01O2Dya6QaVY/xFr8+noERePC + T3jGxTg3h7yDZlfxh7eJ1iy8wzEHCPFwtaryKEeaX50F03nAPXs3o/I2LJdGddRZcbmr + Y2R5XFTMiddb/4vHfPox69ql7JzMao6X4TrBfyFwIjJ6F5J2W3NT43Ag74d4tayQXHIL + j7uA== +X-Gm-Message-State: + ALoCoQmhcpGHBS1IcZkiAteABSPgfqLdyyP1VnS1+OwzkNPw3Q4eOo6M4wg4EsbrqF+jg5NuE2uW +X-Received: by 10.195.13.168 with SMTP id ez8mr54050000wjd.30.1423589924495; + Tue, 10 Feb 2015 09:38:44 -0800 (PST) +Received: from disaster-area.hh.sledj.net + ([2a01:348:1a2:1:ea39:35ff:fe2c:a227]) + by mx.google.com with ESMTPSA id q5sm19789277wix.0.2015.02.10.09.38.42 + (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); + Tue, 10 Feb 2015 09:38:42 -0800 (PST) +Received: from localhost (30000@localhost [local]); + by localhost (OpenSMTPD) with ESMTPA id 48873dfc; + Tue, 10 Feb 2015 17:38:41 +0000 (UTC) +To: Nils Dagsson Moskopp , + Tomi Ollila , 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: none +From: David Edmondson +Date: Tue, 10 Feb 2015 17:38:41 +0000 +Message-ID: +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: Tue, 10 Feb 2015 17:38:50 -0000 + +On Tue, Feb 10 2015, Nils Dagsson Moskopp wrote: +> 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? +> +>> 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 */] + +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, +> --=20 +> Nils Dagsson Moskopp // erlehmann +> +> _______________________________________________ +> notmuch mailing list +> notmuch@notmuchmail.org +> http://notmuchmail.org/mailman/listinfo/notmuch