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

[Luc Teirlinck]

Richard Stallman wrote:

          If one has a bunch of marked files including . and .. , I am
          personally not even really sure what the result of R , C , S
          , H , and some others _ought_ to be. These commands would
          operate on different levels of the directory tree, with
          potentially confusing results.

       You are right.  It seems to me now that I never used "S" on ".".
       Sorry for the misleading remark.

   It seems pretty clear to me what these operations would do, including
   S, for example--making a link to `.' or `..' is like making a link to
   `foo'.

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.  This may
at first sound counterintuitive, but, for reasons I explained in an
earlier message, it seems to me to be clearly the right thing.

On the other hand if you do ^ and hence are on to the `a' entry of ~/,
then they should rename, copy, symlink, hardlink ~/a to ~/b/a.  The
difference is that now we are operating on the directory ~/a.

We are also starting out to operate on ~/a from ~/a/. , because ~/a
happens to be the current directory.  But in the target directory ~/b,
the current directory is ~/b, not a.  So we are trying to rename,
copy, symlink, hardlink ~/a/., that is ~/a, to ~/b/., that is ~/b,
threatening to overwrite ~/b.  There is no `a' in sight here, because
the `.' in ~/b/. now refers to b, not a.  In my view, this is not a
bug, but consistent with shell behavior.

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.  (At least not from a shell's point of
view.)  Treating them as variables would very much confuse people used
to shell type behavior.

In bash all these commands would yield an error when applied to ~/a/.,
because bash will not allow you to overwrite ~/b, unless you use
certain options.

I believe that there are three possibilities:

1.  Completely revert to the old behavior.  Point out in the relevant
    section of the Emacs manual that R, C, S, H all treat `.' and `..'
    in the same way as the shell does, namely as string constants.

2.  Decide that if the user tries to operate on `.' or `..'  it will
    usually not be to "take advantage" of the above "feature", but
    because he does not know what he is doing or because he marked `.'
    and/or `..' by accident.  Keep the current disabling of nearly all
    commands acting on `.' and `..'  Mention this in the Emacs manual.

3.  If we go for 2., then the `.' and `..' in the dired listing might
    become more of a nuisance than a help (it is easy to have them
    marked by mistake).  So, instead, we could revert to the old
    behavior, as in 1., but change the default-value of
    dired-listing-switches from "-alt" to "-Alt".  Going to `..' is
    easy anyway: just type ^.

I did make all suggested changes, assuming we would go for 2., but
reverting all these changes is easy.  I believe there is some logic in
3.  It would shield most people from trouble and allow
super-sophisticated users who actually want to take advantage of the
above feature, to do so by simply changing dired-listing-switches back
to "-alt".

Sincerely,

Luc.