[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#27986: 26.0.50; 'rename-file' can rename files without confirmation
From: |
Eli Zaretskii |
Subject: |
bug#27986: 26.0.50; 'rename-file' can rename files without confirmation |
Date: |
Mon, 11 Sep 2017 20:09:48 +0300 |
> Cc: monnier@IRO.UMontreal.CA, johnw@gnu.org, rms@gnu.org,
> p.stephani2@gmail.com, 27986@debbugs.gnu.org, michael.albinus@gmx.de
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 11 Sep 2017 09:45:48 -0700
>
> On 09/11/2017 07:47 AM, Eli Zaretskii wrote:
> > do these changes modify interactive
> > behavior in incompatible ways? I thought we agreed to leave the
> > interactive behavior intact, and only change the non-interactive uses.
> >
> That wasn't my understanding. In our last email exchange about
> interactivity I proposed that Emacs prompt the user when the destination
> is not a directory name but happens to be a directory (see
> Bug#27986#97), but you were dubious about that (Bug#27986#100) so I left
> it alone.
>
> I normally use dired to rename files in Emacs, and dired's behavior
> hasn't changed as far as I can tell. Where there is a bit of a change is
> when using M-x rename-file directly. Here, in the typical case with file
> name completion there is still no difference, since names of destination
> directories are completed to have trailing /. However, if one uses "M-x
> rename-file foo RET and then laboriously types out the name of an
> existing directory /tmp/destination-dir without using completion and
> without trailing / before hitting RET, one will notice a difference:
> rename-file will now say "File /tmp/destination-dir already exists;
> rename to it anyway? (yes or no)" and if one types "yes" the rename will
> typically fail. So yes, this is a (noisy) incompatibility with previous
> usage. If you like I can go back and implement the suggestion in
> Bug#27986#97; this would be more-compatible with existing usage. I
> suggest leaving it alone, though, as things are simpler and easier to
> explain the way they are.
I think there was a confusion here between interactive and
non-interactive uses of rename-file. For interactive use, AFAIR we
agreed that the behavior should stay as before, in particular to be
consistent with e.g. invocation of 'mv' from the shell prompt.
For non-interactive use, we agreed to change the behavior wrt
directories, with a slight preference to signaling an error even if
the target is an empty directory.