bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~" across platforms

bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~" across platforms

[Jim Porter]

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

bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~" across platforms

[Michael Albinus]

[-- Attachment #1: Type: text/plain, Size: 1714 bytes --]

Jim Porter <jporterbugs@gmail.com> writes:

Hi Jim,

> 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

I've played a little bit with file-name-non-special. The result is the
appended patch, which expands always "/:~"  to the local home
directory. Could you pls check whether it works for you?

Best regards, Michael.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1940 bytes --]

diff --git a/lisp/files.el b/lisp/files.el
index ddae097f1d1..53314752604 100644
--- a/lisp/files.el
+++ b/lisp/files.el
@@ -8317,13 +8317,12 @@ file-name-non-special
 	;; Get a list of the indices of the args that are file names.
 	(file-arg-indices
 	 (cdr (or (assq operation
-			'(;; The first eight are special because they
+			'(;; The first seven are special because they
 			  ;; return a file name.  We want to include
 			  ;; the /: in the return value.  So just
 			  ;; avoid stripping it in the first place.
                           (abbreviate-file-name)
                           (directory-file-name)
-                          (expand-file-name)
                           (file-name-as-directory)
                           (file-name-directory)
                           (file-name-sans-versions)
@@ -8332,6 +8331,10 @@ file-name-non-special
 	                  ;; `identity' means just return the first
 			  ;; arg not stripped of its quoting.
 			  (substitute-in-file-name identity)
+                          ;; `expand-file-name' shall do special case
+                          ;; for the first argument starting with
+                          ;; "/:~".  (Bug#65685)
+                          (expand-file-name expand-file-name)
 			  ;; `add' means add "/:" to the result.
 			  (file-truename add 0)
                           ;;`insert-file-contents' needs special handling.
@@ -8387,6 +8390,10 @@ file-name-non-special
     (let ((tramp-mode (and tramp-mode (eq method 'local-copy))))
       (pcase method
         ('identity (car arguments))
+        ('expand-file-name
+         (when (string-prefix-p "/:~" (car arguments))
+           (setcar arguments (file-name-unquote (car arguments) t)))
+         (apply operation arguments))
         ('add (file-name-quote (apply operation arguments) t))
         ('buffer-file-name
          (let ((buffer-file-name (file-name-unquote buffer-file-name t)))

bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~" across platforms

[Jim Porter]

On 10/3/2023 4:22 AM, Michael Albinus wrote:
> I've played a little bit with file-name-non-special. The result is the
> appended patch, which expands always "/:~"  to the local home
> directory. Could you pls check whether it works for you?

Thanks for the patch. I tested this on GNU/Linux and MS-Windows, and it 
behaves as expected for local files, but Tramp filenames from MS-Windows 
to a remote GNU/Linux seem wrong (though they were wrong before this 
patch too).

Before the patch (on Emacs 29.1), if I open "/ssh:remote:/:~", then 
Emacs opens the file "/ssh:remote:/:/Users/Jim/AppData/Local/Temp/~".

After the patch, Emacs opens the file "/ssh:remote:/Users/Jim/Documents".

Based on the direction in your patch, I'd expect Emacs to open 
"/ssh:remote:/home/jim/".

(I imagine a similar issue could occur on a local GNU/Linux system, but 
going from a local MS-Windows to a remote GNU/Linux has the benefit that 
the two systems have obviously-different directory layouts.)

bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~" across platforms

[Michael Albinus]

Jim Porter <jporterbugs@gmail.com> writes:

Hi Jim,

> Before the patch (on Emacs 29.1), if I open "/ssh:remote:/:~", then
> Emacs opens the file "/ssh:remote:/:/Users/Jim/AppData/Local/Temp/~".
>
> After the patch, Emacs opens the file "/ssh:remote:/Users/Jim/Documents".
>
> Based on the direction in your patch, I'd expect Emacs to open
> "/ssh:remote:/home/jim/".

This is a Tramp bug. I've fixed this in the emacs-29 branch, and merged
it to the master branch afterwards. The fix shall solve both scenarios,
with and without the patch I've posted earlier here.

Could you pls test, whether the patch behaves now as intended?

Best regards, Michael.

bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~" across platforms

[Jim Porter]

On 10/13/2023 7:26 AM, Michael Albinus wrote:
> This is a Tramp bug. I've fixed this in the emacs-29 branch, and merged
> it to the master branch afterwards. The fix shall solve both scenarios,
> with and without the patch I've posted earlier here.
> 
> Could you pls test, whether the patch behaves now as intended?

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.

bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~" across platforms

[Michael Albinus]

Version: 29.2

Jim Porter <jporterbugs@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.

bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~" across platforms

[Eli Zaretskii]

> Cc: 65685@debbugs.gnu.org
> Date: Fri, 13 Oct 2023 17:31:32 -0700
> From: Jim Porter <jporterbugs@gmail.com>
> 
> On 10/13/2023 7:26 AM, Michael Albinus wrote:
> > This is a Tramp bug. I've fixed this in the emacs-29 branch, and merged
> > it to the master branch afterwards. The fix shall solve both scenarios,
> > with and without the patch I've posted earlier here.
> > 
> > Could you pls test, whether the patch behaves now as intended?
> 
> 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.

The added test fails on MS-Windows:

  Test files-tests-file-name-non-special-expand-file-name-tilde condition:
      (ert-test-failed
       ((should
	 (equal
	  (expand-file-name nospecial)
	  (expand-file-name ...)))
	:form
	(equal "/:c:/Documents and Settings/Zaretzky/Local Settings/Temp/files-testsvIKNPk/files-testse2cUFY" "c:/Documents and Settings/Zaretzky/Local Settings/Temp/files-testsvIKNPk/files-testse2cUFY")
	:value nil :explanation
	(arrays-of-different-length 92 90 "/:c:/Documents and Settings/Zaretzky/Local Settings/Temp/files-testsvIKNPk/files-testse2cUFY" "c:/Documents and Settings/Zaretzky/Local Settings/Temp/files-testsvIKNPk/files-testse2cUFY" first-mismatch-at 0)))

I tried to understand the idea of the change, or even the actual root
cause of the problem, but couldn't find that in the discussion or the
code.  It doesn't help that file-name-non-special has no doc string
and no documentation I could find about what it's supposed to do.

Let's please discuss this now, because I tend just to revert the
change on the emacs-29 branch, as it's too late there for untested
ideas for obscure problems.

bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~" across platforms

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

> The added test fails on MS-Windows:
>
>   Test files-tests-file-name-non-special-expand-file-name-tilde condition:
>       (ert-test-failed
>        ((should
> 	 (equal
> 	  (expand-file-name nospecial)
> 	  (expand-file-name ...)))
> 	:form
> 	(equal "/:c:/Documents and Settings/Zaretzky/Local Settings/Temp/files-testsvIKNPk/files-testse2cUFY" "c:/Documents and Settings/Zaretzky/Local Settings/Temp/files-testsvIKNPk/files-testse2cUFY")
> 	:value nil :explanation
> 	(arrays-of-different-length 92 90 "/:c:/Documents and Settings/Zaretzky/Local Settings/Temp/files-testsvIKNPk/files-testse2cUFY" "c:/Documents and Settings/Zaretzky/Local Settings/Temp/files-testsvIKNPk/files-testse2cUFY" first-mismatch-at 0)))
>
> I tried to understand the idea of the change, or even the actual root
> cause of the problem, but couldn't find that in the discussion or the
> code.  It doesn't help that file-name-non-special has no doc string
> and no documentation I could find about what it's supposed to do.
>
> Let's please discuss this now, because I tend just to revert the
> change on the emacs-29 branch, as it's too late there for untested
> ideas for obscure problems.

Please give me a day to check the situation on MS Windows. I don't
believe the change would hurt Emacs 29 in any way, handling "/:~"
doesn't happen in real life I believe. It is just a preparation for a
planned change in Eshell.

I know, "Famous last words" and alike ...

Best regards, Michael.

bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~" across platforms

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> So with the patch you merged to Tramp, plus your other one for
>> "lisp/files.el", I think this is all working consistently now.
>
> The added test fails on MS-Windows:
>
>   Test files-tests-file-name-non-special-expand-file-name-tilde condition:
>       (ert-test-failed
>        ((should
> 	 (equal
> 	  (expand-file-name nospecial)
> 	  (expand-file-name ...)))
> 	:form
> 	(equal "/:c:/Documents and Settings/Zaretzky/Local Settings/Temp/files-testsvIKNPk/files-testse2cUFY" "c:/Documents and Settings/Zaretzky/Local Settings/Temp/files-testsvIKNPk/files-testse2cUFY")
> 	:value nil :explanation
> 	(arrays-of-different-length 92 90 "/:c:/Documents and Settings/Zaretzky/Local Settings/Temp/files-testsvIKNPk/files-testse2cUFY" "c:/Documents and Settings/Zaretzky/Local Settings/Temp/files-testsvIKNPk/files-testse2cUFY" first-mismatch-at 0)))
>
> I tried to understand the idea of the change, or even the actual root
> cause of the problem, but couldn't find that in the discussion or the
> code.  It doesn't help that file-name-non-special has no doc string
> and no documentation I could find about what it's supposed to do.
>
> Let's please discuss this now, because I tend just to revert the
> change on the emacs-29 branch, as it's too late there for untested
> ideas for obscure problems.

I cannot reproduce the problem. My environment:

- MS Windows 10 VM
- MSYS2 MinGW 64-bit
- A fresh git checkout of the master branch, at commit
  548bc3e3d18ea6776032ca83dafbc89e3ddb5a5a
- Emacs recompiled, it reports "GNU Emacs 30.0.50 (build 13,
  x86_64-w64-mingw32) of 2023-10-14"
- Running "$ make -C test files-tests" yields

--8<---------------cut here---------------start------------->8---
Ran 113 tests, 111 results as expected, 0 unexpected, 2 skipped (2023-10-14 12:49:06+0200, 7.219525 sec)

2 skipped results:
  SKIPPED  files-tests-file-name-non-special--subprocess
  SKIPPED  files-tests-file-name-non-special-dired-compress-handler
--8<---------------cut here---------------end--------------->8---

What is the difference to your setup?

Best regards, Michael.

bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~" across platforms

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Jim Porter <jporterbugs@gmail.com>,  65685@debbugs.gnu.org
> Date: Sat, 14 Oct 2023 12:56:07 +0200
> 
> I cannot reproduce the problem. My environment:
> 
> - MS Windows 10 VM
> - MSYS2 MinGW 64-bit
> - A fresh git checkout of the master branch, at commit
>   548bc3e3d18ea6776032ca83dafbc89e3ddb5a5a
> - Emacs recompiled, it reports "GNU Emacs 30.0.50 (build 13,
>   x86_64-w64-mingw32) of 2023-10-14"
> - Running "$ make -C test files-tests" yields

It's Windows XP here, but I doubt that's the problem.  The test fails
for me both on master and on the emacs-29 branch, but the latter is my
worry, since I intend to start the pretest of Emacs 29.2 very soon.

> --8<---------------cut here---------------start------------->8---
> Ran 113 tests, 111 results as expected, 0 unexpected, 2 skipped (2023-10-14 12:49:06+0200, 7.219525 sec)
> 
> 2 skipped results:
>   SKIPPED  files-tests-file-name-non-special--subprocess
>   SKIPPED  files-tests-file-name-non-special-dired-compress-handler
> --8<---------------cut here---------------end--------------->8---
> 
> What is the difference to your setup?

I do

   $ cd test
   $ make lisp/files-tests

and get this:

  Ran 112 tests, 109 results as expected, 1 unexpected, 2 skipped (2023-10-14 14:18:07+0300, 9.375000 sec)

  1 unexpected results:
     FAILED  files-tests-file-name-non-special-expand-file-name-tilde

  2 skipped results:
    SKIPPED  files-tests-file-name-non-special--subprocess
    SKIPPED  files-tests-file-name-non-special-dired-compress-handler

The only difference I could think of is that the directory Emacs uses
here has whitespace in its name (see my original report), whereas on
Windows 10 it probably doesn't.

bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~" across platforms

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

> The only difference I could think of is that the directory Emacs uses
> here has whitespace in its name (see my original report), whereas on
> Windows 10 it probably doesn't.

FTR, if I use a directory with spaces in its name, it fails for me as
well. I'm now debugging ...

Best regards, Michael.

bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~" across platforms

[Michael Albinus]

[-- Attachment #1: Type: text/plain, Size: 606 bytes --]

Michael Albinus <michael.albinus@gmx.de> writes:

Hi Eli,

>> The only difference I could think of is that the directory Emacs uses
>> here has whitespace in its name (see my original report), whereas on
>> Windows 10 it probably doesn't.
>
> FTR, if I use a directory with spaces in its name, it fails for me as
> well. I'm now debugging ...

It looks, like it is a problem in the test case code
itself. abbreviate-file-name does not work as I expect in this
combination.

Well, since it isn't needed for the test, the appended patch has fixed
it for me. Would you like to check?

Best regards, Michael.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1125 bytes --]

diff --git a/test/lisp/files-tests.el b/test/lisp/files-tests.el
index 8f6495a293c..07e1be015da 100644
--- a/test/lisp/files-tests.el
+++ b/test/lisp/files-tests.el
@@ -668,12 +668,14 @@ files-tests-file-name-non-special-expand-file-name-tilde
         abbreviated-home-dir)
     (files-tests--with-temp-non-special (tmpfile nospecial)
       (let (file-name-handler-alist)
-        (setq nospecial (file-name-quote (abbreviate-file-name tmpfile))))
+        (setq nospecial
+              (file-name-quote (concat "~/" (file-name-nondirectory tmpfile)))))
       (should (equal (expand-file-name nospecial)
                      (expand-file-name (file-name-unquote nospecial t)))))
     (files-tests--with-temp-non-special-and-file-name-handler (tmpfile nospecial)
       (let (file-name-handler-alist)
-        (setq nospecial (file-name-quote (abbreviate-file-name tmpfile))))
+        (setq nospecial
+              (file-name-quote (concat "~/" (file-name-nondirectory tmpfile)))))
       (should-not
        (equal (expand-file-name nospecial)
               ;; The file name handler deletes the ".special" extension.

bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~" across platforms

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: jporterbugs@gmail.com,  65685@debbugs.gnu.org
> Date: Sat, 14 Oct 2023 18:48:16 +0200
> 
> >> The only difference I could think of is that the directory Emacs uses
> >> here has whitespace in its name (see my original report), whereas on
> >> Windows 10 it probably doesn't.
> >
> > FTR, if I use a directory with spaces in its name, it fails for me as
> > well. I'm now debugging ...
> 
> It looks, like it is a problem in the test case code
> itself. abbreviate-file-name does not work as I expect in this
> combination.

Can you tell more about this?  I'm surprised any file-related
primitive in Emacs cares about whitespace in file names.

> Well, since it isn't needed for the test, the appended patch has fixed
> it for me. Would you like to check?

I'd like to better understand the issue first.

bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~" across platforms

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> >> The only difference I could think of is that the directory Emacs uses
>> >> here has whitespace in its name (see my original report), whereas on
>> >> Windows 10 it probably doesn't.
>> >
>> > FTR, if I use a directory with spaces in its name, it fails for me as
>> > well. I'm now debugging ...
>>
>> It looks, like it is a problem in the test case code
>> itself. abbreviate-file-name does not work as I expect in this
>> combination.
>
> Can you tell more about this?  I'm surprised any file-related
> primitive in Emacs cares about whitespace in file names.

Perhaps we have uncovered a bug in abbreviate-file-name, don't
know. I'll check when time permits.

However, it isn't related to the change in question of this bug report,
handling expand-file-name for constructs like "/:~..." and
"/ssh:host:/:~...".  abbreviate-file-name has been used to create a
temporary test file for this case, it isn't target of the test itself.

Best regards, Michael.

bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~" across platforms

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: jporterbugs@gmail.com,  65685@debbugs.gnu.org
> Date: Sun, 15 Oct 2023 09:11:19 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> Hi Eli,
> 
> >> >> The only difference I could think of is that the directory Emacs uses
> >> >> here has whitespace in its name (see my original report), whereas on
> >> >> Windows 10 it probably doesn't.
> >> >
> >> > FTR, if I use a directory with spaces in its name, it fails for me as
> >> > well. I'm now debugging ...
> >>
> >> It looks, like it is a problem in the test case code
> >> itself. abbreviate-file-name does not work as I expect in this
> >> combination.
> >
> > Can you tell more about this?  I'm surprised any file-related
> > primitive in Emacs cares about whitespace in file names.
> 
> Perhaps we have uncovered a bug in abbreviate-file-name, don't
> know. I'll check when time permits.

I'd like to understand this sooner rather than latter.  Can you show
some simple recipe which fails under these conditions?

> However, it isn't related to the change in question of this bug report,
> handling expand-file-name for constructs like "/:~..." and
> "/ssh:host:/:~...".  abbreviate-file-name has been used to create a
> temporary test file for this case, it isn't target of the test itself.

I applied your changes to the test, and it passes after that, thanks.

bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~" across platforms

[Michael Albinus]

[-- Attachment #1: Type: text/plain, Size: 2005 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> >> >> The only difference I could think of is that the directory Emacs uses
>> >> >> here has whitespace in its name (see my original report), whereas on
>> >> >> Windows 10 it probably doesn't.
>> >> >
>> >> > FTR, if I use a directory with spaces in its name, it fails for me as
>> >> > well. I'm now debugging ...
>> >>
>> >> It looks, like it is a problem in the test case code
>> >> itself. abbreviate-file-name does not work as I expect in this
>> >> combination.
>> >
>> > Can you tell more about this?  I'm surprised any file-related
>> > primitive in Emacs cares about whitespace in file names.
>>
>> Perhaps we have uncovered a bug in abbreviate-file-name, don't
>> know. I'll check when time permits.
>
> I'd like to understand this sooner rather than latter.  Can you show
> some simple recipe which fails under these conditions?

I haven't completed all tests yet, still in debugging. As recent
result, I believe abbreviate-file-name works correctly.

Rather, the problem seems to be with temporary-file-directory. It is
used in the prelude of the test to set the HOME environment
variable. But later on, in the macros files-tests--with-temp-non-special
and files-tests--with-temp-non-special-and-file-name-handler, it is
modified to (file-truename temporary-file-directory) - this difference
seems to be the culprit.

>> However, it isn't related to the change in question of this bug report,
>> handling expand-file-name for constructs like "/:~..." and
>> "/ssh:host:/:~...".  abbreviate-file-name has been used to create a
>> temporary test file for this case, it isn't target of the test itself.
>
> I applied your changes to the test, and it passes after that, thanks.

Could you pls apply the appended patch instead? I'll continue to finish
all my tests, but if this patch passes also in your environment, it
would give me sufficient confidence that it is fixed.

Best regards, Michael.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 681 bytes --]

diff --git a/test/lisp/files-tests.el b/test/lisp/files-tests.el
index 8f6495a293c..78d469580ba 100644
--- a/test/lisp/files-tests.el
+++ b/test/lisp/files-tests.el
@@ -664,7 +664,8 @@ files-tests-file-name-non-special-expand-file-name

 (ert-deftest files-tests-file-name-non-special-expand-file-name-tilde ()
   (let ((process-environment
-         (cons (format "HOME=%s" temporary-file-directory) process-environment))
+         (cons (format "HOME=%s" (file-truename temporary-file-directory))
+               process-environment))
         abbreviated-home-dir)
     (files-tests--with-temp-non-special (tmpfile nospecial)
       (let (file-name-handler-alist)

bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~" across platforms

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: jporterbugs@gmail.com,  65685@debbugs.gnu.org
> Date: Sun, 15 Oct 2023 11:50:38 +0200
> 
> > I applied your changes to the test, and it passes after that, thanks.
> 
> Could you pls apply the appended patch instead? I'll continue to finish
> all my tests, but if this patch passes also in your environment, it
> would give me sufficient confidence that it is fixed.

After these changes, the tests also pass.

bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~" across platforms

[Michael Albinus]

Version: 29.2

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> Could you pls apply the appended patch instead? I'll continue to finish
>> all my tests, but if this patch passes also in your environment, it
>> would give me sufficient confidence that it is fixed.
>
> After these changes, the tests also pass.

Thanks. Pushed to the emacs-29 branch. Closing the bug.

Best regards, Michael.

bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~" across platforms

[Mattias Engdegård]

After the change, files-tests fail. 

Test files-tests-file-name-non-special-expand-file-name-tilde backtrace:
  signal(ert-test-failed (((should (equal (expand-file-name nospecial)
  ert-fail(((should (equal (expand-file-name nospecial) (expand-file-n
  (if (unwind-protect (setq value-354 (apply fn-352 args-353)) (setq f
  (let (form-description-356) (if (unwind-protect (setq value-354 (app
  (let ((value-354 'ert-form-evaluation-aborted-355)) (let (form-descr
  (let* ((fn-352 #'equal) (args-353 (condition-case err (let ((signal-
  (progn (let (file-name-handler-alist) (setq nospecial (file-name-quo
  (unwind-protect (progn (let (file-name-handler-alist) (setq nospecia
  (let* ((temporary-file-directory (file-truename temporary-file-direc
  (let ((process-environment (cons (format "HOME=%s" temporary-file-di
  (closure (t) nil (let ((process-environment (cons (format "HOME=%s" 
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name files-tests-file-name-non-special-exp
  ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
  ert-run-tests((not (or (tag :unstable) (tag :nativecomp))) #f(compil
  ert-run-tests-batch((not (or (tag :unstable) (tag :nativecomp))))
  ert-run-tests-batch-and-exit((not (or (tag :unstable) (tag :nativeco
  eval((ert-run-tests-batch-and-exit '(not (or (tag :unstable) (tag :n
  command-line-1(("-L" ":../../emacs/test" "-l" "ert" "-l" "lisp/files
  command-line()
  normal-top-level()
Test files-tests-file-name-non-special-expand-file-name-tilde condition:
    (ert-test-failed
     ((should (equal (expand-file-name nospecial) (expand-file-name ...)))
      :form
      (equal
       "/:/private/var/folders/qy/zstv16390nlcs47kz8nff_mm0000gn/T/files-testsgcrggv/files-testsHn7mpT"
       "/private/var/folders/qy/zstv16390nlcs47kz8nff_mm0000gn/T/files-testsgcrggv/files-testsHn7mpT")
      :value nil :explanation
      (arrays-of-different-length 94 92
				  "/:/private/var/folders/qy/zstv16390nlcs47kz8nff_mm0000gn/T/files-testsgcrggv/files-testsHn7mpT"
				  "/private/var/folders/qy/zstv16390nlcs47kz8nff_mm0000gn/T/files-testsgcrggv/files-testsHn7mpT"
				  first-mismatch-at 1)))
   FAILED   45/113  files-tests-file-name-non-special-expand-file-name-tilde (0.000818 sec) at ../../emacs/test/lisp/files-tests.el:686

bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~" across platforms

[Michael Albinus]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

Hi Mattias,

> After the change, files-tests fail.
>
>    FAILED   45/113  files-tests-file-name-non-special-expand-file-name-tilde (0.000818 sec) at ../../emacs/test/lisp/files-tests.el:686

This is the master branch, isn't it? The emacs-29 branch has 112 test
cases only.

Eli did report this problem already, and I've fixed it in the emacs-29
branch with commit 07c45f20fd3, yesterday.

I've now merged the emacs-29 branch into master. Could you, pls, retest
with a fresh checkout?

Thanks, and best regards, Michael.

bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~" across platforms

[Mattias Engdegård]

16 okt. 2023 kl. 09.07 skrev Michael Albinus <michael.albinus@gmx.de>:

> I've now merged the emacs-29 branch into master. Could you, pls, retest
> with a fresh checkout?

Now it works on master, too. Thank you so much, and sorry about my initial lack of patience.