From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.bugs Subject: bug#65902: 29.0.92; emacsclient-mail.desktop fails due to complicated escaping Date: Thu, 14 Sep 2023 10:04:48 -0400 Message-ID: References: <83ttrym8jx.fsf@gnu.org> <83led9nay9.fsf@gnu.org> <66a6c09e-3b61-d913-5638-4c804fb826f6@gmail.com> <83edj1mja5.fsf@gnu.org> <87il8dt3sh.fsf@catern.com> <83pm2klvw9.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7645"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 65902@debbugs.gnu.org, sbaugh@catern.com, jporterbugs@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Sep 14 16:06:13 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qgmyz-0001hO-4l for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 14 Sep 2023 16:06:13 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qgmyk-0003le-J9; Thu, 14 Sep 2023 10:05:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qgmyj-0003lN-0o for bug-gnu-emacs@gnu.org; Thu, 14 Sep 2023 10:05:57 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qgmyi-0001xM-Kv for bug-gnu-emacs@gnu.org; Thu, 14 Sep 2023 10:05:56 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qgmyo-0007Lu-8r for bug-gnu-emacs@gnu.org; Thu, 14 Sep 2023 10:06:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Sep 2023 14:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65902 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 65902-submit@debbugs.gnu.org id=B65902.169470030328171 (code B ref 65902); Thu, 14 Sep 2023 14:06:02 +0000 Original-Received: (at 65902) by debbugs.gnu.org; 14 Sep 2023 14:05:03 +0000 Original-Received: from localhost ([127.0.0.1]:40684 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qgmxr-0007KJ-1Q for submit@debbugs.gnu.org; Thu, 14 Sep 2023 10:05:03 -0400 Original-Received: from mxout5.mail.janestreet.com ([64.215.233.18]:58635) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qgmxo-0007Jk-3M for 65902@debbugs.gnu.org; Thu, 14 Sep 2023 10:05:01 -0400 In-Reply-To: <83pm2klvw9.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 14 Sep 2023 16:36:06 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:270429 Archived-At: Eli Zaretskii writes: >> From: sbaugh@catern.com >> Date: Thu, 14 Sep 2023 11:03:44 +0000 (UTC) >> Cc: Jim Porter , 65902@debbugs.gnu.org, >> sbaugh@janestreet.com >> >> The issue is not really with the desktop file. It's a generic problem: > > No, it isn't. If it were, we'd have heard about it much sooner, and > not because of the desktop files. > > What you are doing is representing a rare problem related to a niche > feature is if it were a general one, by inventing use cases to justify > that. But if those use cases were important, people would have asked > for them long ago. They didn't. Why? because --eval already exists. No... these are real use cases that I personally have. I have really wanted this for a long time. As I said in my original email, "I expect this to also be useful in other places; the need to escape arbitrary inputs before passing them to emacsclient is frequently annoying." - I've wanted the ability to pass arbitrary data to Emacs through emacsclient since at least 2016, for other reasons: https://lists.gnu.org/archive/html/emacs-devel/2016-06/msg00051.html - The fact that there is currently advice in org-protocol to implement this behavior means there are people who want it. I'm sure the org-protocol authors really wanted to be able to avoid that advice, back when they developed it in 2009. They didn't bother contributing a solution upstream back then, but why stop it from happening now? - It would allow lazy loading of org-protocol as desired by the org devs https://list.orgmode.org/strc07$3o0$1@ciao.gmane.io - I'm working on a package which allows using Emacs to do completing-read over arbitrary strings passed in from the command line, as a replacement for the popular terminal software fzf. Since this is completion over arbitrary strings, I need the ability to get those arbitrary strings into Emacs. - There are numerous examples on the web of users trying and failing to get the quoting right to pass arguments to emacsclient; for example https://www.reddit.com/r/emacs/comments/hhbcg7/emacsclient_eval_with_command_line_arguments/ this would become emacsclient --apply switch-to-buffer https://stackoverflow.com/questions/8848819/emacs-eval-ediff-1-2-how-to-put-this-line-in-to-shell-script this would become emacsclient --apply ediff No shell complexities required in either case. >> > What about alternative solutions: use a shell script in the desktop >> > files, and delegate to that script to solve the problem with quoting? >> > Had anyone considered this strategy? If not, why not? >> >> Getting the quoting right is hard and complex, and even Emacs developers >> have failed at it over multiple iterations, and when they fail it either >> breaks or exposes a security vulnerability. > > Emacs developers make mistakes even in the simple regexps we have in > our code. That doesn't mean we should abandon regexps. The solution > for sending Lisp forms to the server exists, and the quoting, although > tricky in some cases, is not rocket science to get right. I think this (the current contents of emacsclient-mail.desktop): sh -c "u=\\$(echo \\"\\$1\\" | sed 's/[\\\\\\"]/\\\\\\\\&/g'); exec emacsclient --alternate-editor= --display=\\"\\$DISPLAY\\" --eval \\"(message-mailto \\\\\\"\\$u\\\\\\")\\"" sh %u is in fact rocket science, and rocket science that needs to be repeated by every user who wants to pass arbitrary strings to Emacs. And keep in mind this mass of escaping *is currently broken*. > I don't see > why we would need another mechanism to do something similar with > radically different syntax, a separate set of rules and restrictions > that need to be documented, etc. etc. > >> This solution is far simpler > > That's an illusion. There's nothing simple about it. You are > inventing a new mechanism for passing Lisp forms as something other > than Lisp. But I don't want to pass Lisp forms, that's the entire point. I have some arbitrary string which is *not* Lisp, and I want Emacs to *not* parse it as Lisp. > This has got to have issues into which we will bump sooner > or later. E.g., assume that two or more of the arguments to the > function begins with single quote, as in > > $ emacsclient --apply func arg1 'foo arg2 'bar > > Escape-quoting, here we come again! That example works fine with --apply. The call becomes: (func "arg1" "'foo" "arg2" "'bar") which is reliable and expected. Maybe you're referring to how, if you run that command through a shell, the shell interprets the single quotes as creating a string? But that's that's a separate issue, because: - I don't plan to run any of my commands using --apply through a shell (which means they will require zero escaping or quoting whatsoever) - Right now with --eval you have to do escaping for both the shell and Lisp. With --apply you only have to do escaping for the shell, if you do use a shell, and if you don't use a shell you don't have to do anything. I think it is simpler to reduce the amount of quoting and escaping from "both Lisp and shell" to "just shell, and not even that if you don't use a shell".