From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Boruch Baum Newsgroups: gmane.emacs.bugs Subject: bug#48072: 28.0.50: dired-read-shell-command: handle empty input properly [PATCH] Date: Wed, 28 Apr 2021 11:01:44 -0400 Message-ID: <20210428150144.4uxrcguggkh7vrjx@E15-2016.optimum.net> References: <20210427190243.n5yg3gywd5wma3jl@E15-2016.optimum.net> <83lf93h6x1.fsf@gnu.org> <20210427193253.ourhlr3nxdem3e6t@E15-2016.optimum.net> <83k0ongnc7.fsf@gnu.org> <20210428030025.75hiu5zgrll2qzeq@E15-2016.optimum.net> <87fszbnd70.fsf@gmail.com> <20210428095054.wkpyxl2axhdx26dq@E15-2016.optimum.net> <838s52hb7h.fsf@gnu.org> <20210428124952.anyz3ddhgvlcxyj3@E15-2016.optimum.net> <83mttiftnl.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3339"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: NeoMutt/20180716 Cc: 48072@debbugs.gnu.org, kevin.legouguec@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Apr 28 17:04:31 2021 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 1lbljr-0000mO-Pc for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 28 Apr 2021 17:04:31 +0200 Original-Received: from localhost ([::1]:58194 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lbljq-0006C7-RR for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 28 Apr 2021 11:04:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54282) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lblhS-0003sK-Kf for bug-gnu-emacs@gnu.org; Wed, 28 Apr 2021 11:02:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42238) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lblhS-0004wO-70 for bug-gnu-emacs@gnu.org; Wed, 28 Apr 2021 11:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lblhS-0008AE-1d for bug-gnu-emacs@gnu.org; Wed, 28 Apr 2021 11:02:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Boruch Baum Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 28 Apr 2021 15:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48072 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 48072-submit@debbugs.gnu.org id=B48072.161962211831189 (code B ref 48072); Wed, 28 Apr 2021 15:02:01 +0000 Original-Received: (at 48072) by debbugs.gnu.org; 28 Apr 2021 15:01:58 +0000 Original-Received: from localhost ([127.0.0.1]:53784 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lblhO-00086a-4A for submit@debbugs.gnu.org; Wed, 28 Apr 2021 11:01:58 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:40349) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lblhL-0007za-2J for 48072@debbugs.gnu.org; Wed, 28 Apr 2021 11:01:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1619622107; bh=wvWJiPz+Ku4P3Pz7R+BBWK7tytXCsA9Te6xjrexklgI=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:References:In-Reply-To; b=Y2YiLxdewJeP3ZXgJWilyFNm6O6XDIYdWkcrkQjTFkY/I54xzrLV09ni3zmJDDM4v HN+brC7RS6VEa4VkgkkPBEgHGO2TbofZlG+8x1Z/qn1rxB1JN0OTqb9HSYf6m7RHq9 D0H6fibKWyGpPOQqNa56SNXfYQ3d8uH1drVSAV0w= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from E15-2016.optimum.net ([70.19.86.82]) by mail.gmx.net (mrgmx105 [212.227.17.174]) with ESMTPSA (Nemesis) id 1N0XD2-1lPixD14eS-00wY3Q; Wed, 28 Apr 2021 17:01:47 +0200 Content-Disposition: inline In-Reply-To: <83mttiftnl.fsf@gnu.org> X-Provags-ID: V03:K1:XsNaw9qexGVGCgpfWrq2hcnbW1TD0BpEf4BpLb+S9Geq8qfOlkR MW1Z0uVaERTEUD5LO8MQUwyrfeP897kcgAI64rRqCsvXNSI5OTywzHHev4Tw7gGDW8FUy9V Jb+/xUtfhH6G9MZVt6SH4T6tCT6azxINpjqrav5VWYpP1+X5quUlj7wjZAUsDr6UG6Znp5i kGWeTKFt66TdomnYCeVeA== X-UI-Out-Filterresults: notjunk:1;V03:K0:jfJBKIGJfAE=:na4y+GYEchsq8wwYi/kKm2 +KmguMuwu6oZFj61yDOXDudK/bHHsZhA0bhOu3KE3lbhkBs7HflqbxKjoQPLtijGAt3aJUDiR MREwb2wLbpI/VTskNVdS70LZfNQjDmCx26x5WQHMYdRFZXm7Qg5cGkqtobkSx1ZkpzVzeiJAt B1pmK7tPMFmqZcnXrOKfheDIQuekm9T+RGcVNRT0+Mb8OrIEJwSKew73qHNIDHwjbEptIfyaS CZRvqsqbyjQdoCG+KPRSSz+6mwcE2Zxd/npDN28iSvzP0FZGloNXxjgN99yL9UiPvZX2ddl8I Art4BRrexcvgawI6TfKqezWRSFIRx3WCR2QXIiE9/mbfOp/OGy5s+CGpbKfbr9Eli3QGwnzha HT5NX3z4KT1c4gCcY3V311LDF8pM1gJ9HuYhbtenT+8hv+JAm9h9LrQVuK1YJIf+LREdmZLDL jj/gic+IGSSriucIJjNgCRnXf1yXch5VCG0z3ySCJWqZRHu0tNdymj+TJ0fm5yhFPGbLuYe+2 Rtv2vP6LW8AhSHfEnhLNv19LqexKKxlg0j7vF84HR6EtTZl/LrKyn/lBAB2KJYHsoAjaULm/G N6LNoGQ1aCnTO2davLZyWzdMkV1zlN67wHFAaIi5ljsLYo9GiyBMZxBVL7ufEgPg0QVYrhH3O nFGUSlmIAjdirlsDtvylYdyL9ExGs4Bwhc0qJuDiykiolOhkIjrhFOPplQDMh/+CXhzTIjF42 2lnQNgjwFtV/TwJaXYm0k01gPPaI2phP+fXpNXhh3lcPXF+2bCeTQse1gFqKW4Bexs2KE449 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" Xref: news.gmane.io gmane.emacs.bugs:205117 Archived-At: On 2021-04-28 16:03, Eli Zaretskii wrote: > > Date: Wed, 28 Apr 2021 08:49:52 -0400 > > From: Boruch Baum > > Cc: kevin.legouguec@gmail.com, 48072@debbugs.gnu.org > > > > On 2021-04-28 14:58, Eli Zaretskii wrote: > > > > Date: Wed, 28 Apr 2021 05:50:54 -0400 > > > > From: Boruch Baum > > > > Cc: Eli Zaretskii , 48072@debbugs.gnu.org > > > > > > > > I could restrict the check to the preparation of list of completio= n > > > > candidates for the defaults put into the mini-buffer history (alre= ady > > > > done in diredc, as an advice around function dired-guess-default),= and > > > > give dired users feedback when a command returns an error conditio= n (on > > > > this week's plan anyway). > > > > > > I'm not sure I understand what you are suggesting. Do you mean set = up > > > the completion candidates so that they would only include executable > > > files found on the system, but allow users also to type commands tha= t > > > are not among the completion candidates? I think this could be > > > confusing, and I don't think we have a precedent for such a behavior > > > elsewhere. > > > > I don't understand what your point of confusion is, but it's your call= , > > of course. Your position has emacs offering users impossible choices, > > choices guaranteed to fail. > > I'm asking you to help me understand the details of restricting the > check that you are proposing. Once I understand that, I could make up > my mind about the proposal. Right now I simply don't understand it. You had that idea correct in your prior paragraph, where your wrote: "set up the completion candidates so that they would only include executable files found on the system, but allow users also to type commands that are not among the completion candidates" What I can add is: 1) the completion candidates would be the subset of elements of the emacs variables `dired-guess-shell-alist-user' and `dired-guess-shell-alist-default' (diredc adds `diredc-shell-guess-fall= back') which satisfy function `executable-find'; 2) the user would face no constraint whatsoever in what could be entered. 2.1) I have mixed feelings about this, because for asynchronous operations any typographic error silently fails and yields a misleading message that can easily be interpreted as a successful completion. 2.1.1) Try the following in a vanilla dired buffer: Navigate POINT to a fi= le, let's say 'bar', and press '&' for the async command. Then type in = some garbage command, let's say 'foo', and . The response I get is = a message in the mini-buffer: "foo bar&wait: finished." (BTW, I haven= 't figured out where that message is being generated; anyone's help wo= uld be appreciated; I would like to see if it can report errors). 2.1.2) It would be nice to get feedback from dired power users about how t= hey use the '!' and '&' commands in practice. My experience and observa= tion is that even power users use those commands for straightforward operations and use shell built-ins from either a shell buffer or a shell-script buffer. (note that some built-ins also have correspond= ing executables, eg '['). 2.1.3) My gut feeling is that everyone will appreciate getting feedback on= an invalid command, and no-one would mind not being able to use shell built-ins. Thus, I prefer having the constraint. 2.2) The constraint as written only checks the initial atom of the command= line, so it wouldn't catch "sort ? | uniqqq". =2D- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0