Re: dired-do-rename on "." and ".."

[Luc Teirlinck]

Richard Stallman wrote:

       If, in directory ~/a, you put the cursor on `.', then I believe that
       typing R, C ,S and H and then specifying ~/b as target directory,
       assuming that they are going to do anything else than throwing an
       error, all should do what they _all_ (and not just R) used to do
       before your patch: warn that you are about to overwrite ~/b.

   That's assuming directory ~/b exists.  If it doesn't, then R
   would do something bizarre.

In that case, I am not going to try it out and learn the hard way what
that "something bizarre" is.  I actually like my file system.  My
guess is that it would throw an error, as in any other case I checked,
where you try to use a non-existing directory as target for R, C, H or
S.  If it does something horrible instead, I guess we could easily
change the code to make it throw an error.

   So I believe R should refuse to operate on ., and C also.
   That is the current behavior.

   However, there's no reason S, H, M, etc. should not allow
   these special dir names.

The behavior of R, C, S and H all could potentially confuse the user.
It confused Markus and I believe it confused both of us for a while.
M, G and O are no problem.  With ! , it is up to the user not to
out-trick himself (which is very easy to do: you can use, for instance
mv and have the same surprises as with R).

I do not understand why you worry about R and C, and not about H and
S.  Actually H and S are the two completely nonsensical ones.

Comment out your change.  Create two directories ~/junkdir/a and
~/junkdir/b. (The extra level junkdir is just to avoid trouble when
accidentally putting the cursor on .. instead of .)

Create a file file1 in ~/junkdir/a and a file2 in ~/junkdir/b.

Visit ~/junkdir/a and put the cursor on `.'.  Now R, H and S all
produce errors after one answers y or yes to all questions.  Better to
throw an error immediately.  C does something.  It does not seem to
matter what one answers to the "overwrite" question, just answer yes
to the "recursively copy?" question.  ~/junkdir/b now contains both
file1 and file2, that is the _contents_ of ~/junkdir/a got copied into
~/junkdir/b without deleting anything.  Among the four, this is
clearly the only potentially useful behavior.

Now delete file2 in ~/junkdir/b, to make this directory empty.  S and H
still produce errors, after asking some senseless questions.  If any
of the four should throw an error immediately, then it is these two.
R renames ~/junkdir/a to ~/junkdir/b.  C still does exactly the same
as before (when asking yes to the "copy recursively?" question).  If
any of these commands actually make sense, it is C.

        The trick is that "." and ".." are string constants, whereas the
        notion that . in ~/a should act exactly like a in ~/ treats them
        as
        variables, which they are not.

    Sorry, you have lost me here.

Well, remember that Markus expected that with the cursor on `.' in
~/junkdir/a, R would rename ~/junkdir/a to ~/junkdir/a/b and we
actually both agreed with him for a while.  I do not anymore.  I do
not know whether you still do.  How could that behavior possibly make
sense?  We are copying the filename (a string constant) "." from
~/junkdir/a to `/junkdir/b, that is ~/junkdir/a/. (which is, as an
actual file, ~/junkdir/a) to ~/junkdir/b/. that is, ~/junkdir/b,
exactly what happened before your change and should happen, except for
the fact that it seems to confuse people and hence might represent a
certain danger, even though, even before your change, the user
actually gets warned that he is misunderstanding things and gets
informed about what will really happen.

The question is whether any of the above functionality is worth the
danger of confusing some users.  H and S have no functionality, so the
question applies only to R and C.

The variable stuff is not very relevant, it is just speculation on
where the confusion came from.  I believe that the notion that R
should actually rename ~/junkdir/a/. to ~/junkdir/b/a rather than to
~/junkdir/b is due to the fact that people tend to think of `.' and
`..' as some kind of "variables" that _always_ get replaced with their
"values", the current and parent directories, in this case "." would
"evaluate" to "~/junkdir/a" and ".." would "evaluate" to "~/junkdir".
This is definitely not the way the shell thinks of them and trying to
think of them that way would, I believe, lead to all kinds of
weirdness in more complex situations.  Instead, "." and ".." are
strings, just like any other filename, the only difference being that
once filenames actually get interpreted as filenames and _only_ at
that stage, `.' and `..' get their special meaning.  This perfectly
explains all behavior above, which is consistent with shell behavior.

Sincerely,

Luc.