From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Boruch Baum Newsgroups: gmane.emacs.bugs Subject: bug#34338: 26.1; delete-file return codes and failures Date: Wed, 6 Feb 2019 16:02:11 -0500 Message-ID: <20190206210211.f6ugtim5ie22nkd4@E15-2016.optimum.net> References: <20190205214737.vswyk7sfmgkliv7v@E15-2016.optimum.net> <83r2cksxdt.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="153819"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: NeoMutt/20180716 Cc: 34338@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Feb 06 22:03:23 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1grULq-000dqu-Sh for geb-bug-gnu-emacs@m.gmane.org; Wed, 06 Feb 2019 22:03:23 +0100 Original-Received: from localhost ([127.0.0.1]:58555 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1grULp-0005K5-Tz for geb-bug-gnu-emacs@m.gmane.org; Wed, 06 Feb 2019 16:03:21 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:52981) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1grULh-0005Iw-5B for bug-gnu-emacs@gnu.org; Wed, 06 Feb 2019 16:03:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1grULg-0006Xs-7L for bug-gnu-emacs@gnu.org; Wed, 06 Feb 2019 16:03:13 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36934) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1grULX-0006V2-BA for bug-gnu-emacs@gnu.org; Wed, 06 Feb 2019 16:03:06 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1grULV-0008AG-RS for bug-gnu-emacs@gnu.org; Wed, 06 Feb 2019 16:03:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Boruch Baum Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Feb 2019 21:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34338 X-GNU-PR-Package: emacs Original-Received: via spool by 34338-submit@debbugs.gnu.org id=B34338.154948694631078 (code B ref 34338); Wed, 06 Feb 2019 21:03:01 +0000 Original-Received: (at 34338) by debbugs.gnu.org; 6 Feb 2019 21:02:26 +0000 Original-Received: from localhost ([127.0.0.1]:36215 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1grUKw-00084x-9W for submit@debbugs.gnu.org; Wed, 06 Feb 2019 16:02:26 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:40489) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1grUKt-00080B-MB for 34338@debbugs.gnu.org; Wed, 06 Feb 2019 16:02:24 -0500 Original-Received: from E15-2016.optimum.net ([108.6.168.221]) by mail.gmx.com (mrgmx101 [212.227.17.174]) with ESMTPSA (Nemesis) id 0MP0LT-1gnNj73aZb-006Me7; Wed, 06 Feb 2019 22:02:15 +0100 Content-Disposition: inline In-Reply-To: <83r2cksxdt.fsf@gnu.org> X-Provags-ID: V03:K1:jsuYTs9RtaYPkZuxfEAmDBrQQAYFnPK5ZhMP5XtUzs5xxx7K9fd C3zYOZBHUe0ZUh4iurB8tjWAfSojNn7C19/RQNZhS9NJNWfWATewkl6JzNnW97zGHc5adSm dGbGJpVxOloQfirpWHzZzvJGj5Swc4bNbulOpwLScAGl0zM1z+FyQ1rqPdhLpjSyOjUhiAi sBtaHj4w524xHU83Mge6Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:e9k6hEgzZJo=:d0ZclI6+9cwGZ0LteNomxy E4T97GMOeqBBNmEEL/ss/2z9AJwvSmsENDeXOwVzBsktmAj1AJ9Tq7m6gi7MMNQP51p5/yQjM odNCjNpQdLauLhyHpU51Vm/EKnhuYKJ72QOAtlJKVL6w8J8zfLw1BXF448RHG5tL+MwLcLlnX tihN2JNLXABcKiqlpKPdARHK45tGXdJJsMs/4vjfhr7UjkTpZpZK5aSeGleZtW8ggdOWM0siW CXpGvxNIzrFxJbz8HhswkGUUTwqSD98VJJK/cM26+VMITsCuB8NN6gYdV3I3sMQMddZDSBMvl 0SsL7qgt9RpsxbpQHMSeaEzD4fXFy6VsU4PCMFCApNfGRcnu19RNi0BbqQfArhOYPBuPYbh9Y zFijn3vGMVty5KbQyNSXFykvSUDW79QGDcigXxofINXQe4pyvLvLytQPS3p8Kzmgu0+VtP9ux cq59ZrjHubgiL1PqtVQiInuwdhX6QWjVP9QuNT4ZcCThuxN5LAUfMubUYDwYeMPPr5W+N1vH4 Zo50pyZwhtNwdLpjvsVRlnoFWBsptAAkNdvZnyoMWRE7I5K78P66Cyzqw4qaYDlisZV6eSKra 6YHCtAFvKlY9DRsrUsrROmZ7j6JkhOLcCdYnSdHUt8pDRykYejf6b+5ETYRcetD1CX+XvXtcP oezLLUPaH7/DqoTv4k37adT35wfp1byxofmBEZp/v833lHRfaBVjky4AjUJzlHMtFL+S/ZYZW 4swl36H0oVo/VuThESY8sK46TnUWh54lmnumbNqIGa18csUI/243hNYKtl7HhJMa3mg1TxtB X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:155194 Archived-At: On 2019-02-06 18:19, Eli Zaretskii wrote: > > Date: Tue, 5 Feb 2019 16:47:37 -0500 > > From: Boruch Baum > > As Michael points out, there's one optional argument already, and we > need to preserve it. Yup. > > > B2) raise an error when (not NOERROR) and: > > > > B2.1) file doesn't exist > > > > B2.2) (and (chmod -w) (not FORCE)) > > > > B2.3) another form of permission denial is encountered > > !ERROR and either of the following, or all of them? Either. > In any case, you propose a backward-incompatible change in behavior, > so it won't fly. We could perhaps do it the other way around: add a > new optional argument ERROR-OUT, which, when non-nil, will cause the > function to signal an error when B2.1 or B2.2 happen (I believe B2.3 > already causes an error). And similarly with FORCE. > IOW > ... (snip) ... The part that would transform a prior condition of 'crash' to some return value is a kind of backward-incompatibility that I think most people would appreciate. The issue would be if there exists code in emacs that traps on the current crashes (eg. using 'condition-case'). I like the idea of requiring non-nil to force an ERROR-OUT, but that would inconsistent with the more common emacs use of NOERROR as an arg. For a proposed FORCE arg, backward-incompatibility is a positive feature, a bug-fix, in that emacs is not currently respecting a user's environment choice to place a level of protection from deleting the target file. A user made a conscious positive act at some point to put a level of protection on a file, that in the usual context, 'rm', would require further interaction in order to proceed, and emacs is currently not abiding by that. > > C) maybe log the exact error or reason for nil to *Messages*. > > Not sure what you mean by "exact error or reason", I believe we > already log the reason. For me, in response chmod -x $parent_dir, the error message is: eval: Removing old name: Permission denied, /home/boruch/foo/bar And the response to chattr +i bar eval: Removing old name: Operation not permitted, /home/boruch/foo/bar So the messages are unique, but not clear. > Finally, did you think how to allow users set or reset these new knobs > when invoking delete-file interactively? No! Um .... > I think these options are mainly for interactive use, and in that case > we should have some convenient way of setting them interactively. So, currently the prefix arg is already being used for TRASH ... Interactively, having a 'knob' for NOERROR (or its reverse, per above) doesn't seem to me necessary ... what value does it add for an interactive invocation? ... Interactively, for FORCE, there's no 'lossage-advantage' (borrowed term based upon `C-h l') to requiring a user to add keystrokes up-front prior to delete-file, rather than requiring the user to y-or-n if the file has protection. So, that doesn't seem necessary, unless you want to add a feature to allow delete-file to operate on a regex or sequence of filenames instead of a single file. That leaves my off-topic comment to Michael about a THRASH (not TRASH, but maybe better SHRED) arg. My input on that would be to have such a feature as a separate function (eg. shred-file), and not an arg to delete-file. חודש טוב ואדר כפול שמח. -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0