GNU bug report logs -
#65685
29.1; Inconsistent behavior of quoted file name "/:~" across platforms
Previous Next
Reported by: Jim Porter <jporterbugs <at> gmail.com>
Date: Fri, 1 Sep 2023 19:23:01 UTC
Severity: normal
Found in version 29.1
Fixed in version 29.2
Done: Michael Albinus <michael.albinus <at> gmx.de>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Sat, 14 Oct 2023 09:42:00 +0200
with message-id <87fs2d4pmf.fsf <at> gmx.de>
and subject line Re: bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~" across platforms
has caused the debbugs.gnu.org bug report #65685,
regarding 29.1; Inconsistent behavior of quoted file name "/:~" across platforms
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
65685: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65685
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
To see this in action, run 'emacs -Q "/:~"' on both GNU/Linux and
MS-Windows.[1] On GNU/Linux, this opens a dired buffer for the user's
home directory. On MS-Windows, it opens a buffer for a new file named tilde.
According to the Emacs manual:
> ‘/:’ can also prevent ‘~’ from being treated as a special character
> for a user’s home directory. For example, /:/tmp/~hack refers to a
> file whose name is ~hack in directory /tmp.
I'd interpret this to mean that the MS-Windows behavior is correct.
However, the example doesn't specifically say what should happen when
the tilde comes immediately after the "/:". On the very rare occasions
you might need it, you can always spell "a file named tilde in the
current directory" like "/:./~".
This is relevant to some future Eshell changes I'm considering[2], where
(I think) I'd like "/:~" to mean "the user's local home directory, even
when default-directory is remote". In light of that, my selfish
preference is that we keep the GNU/Linux behavior and standardize it
across all systems. However, we could standardize the MS-Windows
behavior instead; I'd then just have to call out the different Eshell
semantics in the Eshell manual.
[1] You can see this inconsistency with other commands too, like "M-x cd
RET /:~ RET".
[2] https://lists.gnu.org/archive/html/emacs-devel/2023-08/msg01244.html
[Message part 3 (message/rfc822, inline)]
Version: 29.2
Jim Porter <jporterbugs <at> gmail.com> writes:
Hi Jim,
> I think this works now, thanks. (Note that I just eval'ed the new
> version of 'tramp-sh-handle-expand-file-name' on MS-Windows to test
> things out, since I don't have a build environment set up on my
> MS-Windows system.)
>
> So with the patch you merged to Tramp, plus your other one for
> "lisp/files.el", I think this is all working consistently now.
Thanks for the feedback, I've pushed it to the repositories. Closing the bug.
Best regards, Michael.
This bug report was last modified 1 year and 221 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.