GNU bug report logs -
#26911
25.2; eshell "cd .." doesn't work correctly with TRAMP
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 26911 in the body.
You can then email your comments to 26911 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Sat, 13 May 2017 16:39:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Yegor Timoshenko <yegortimoshenko <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sat, 13 May 2017 16:39:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Steps to reproduce:
M-x eshell
cd /user <at> remote.com:/
cd bin
cd ..
pwd
Expected output:
/user <at> remote.com:
Actual output:
/user <at> remote.com:/home/user
Reproducible in default Emacs 25.2 install:
In GNU Emacs 25.2.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 10.9.5 (Build 13F1911))
of 2017-04-21 built on builder10-9.porkrind.org
Windowing system distributor 'Apple', version 10.3.1504
Configured using:
'configure --with-ns '--enable-locallisppath=/Library/Application
Support/Emacs/${version}/site-lisp:/Library/Application
Support/Emacs/site-lisp' --with-modules'
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Sat, 13 May 2017 18:26:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 26911 <at> debbugs.gnu.org (full text, mbox):
Yegor Timoshenko <yegortimoshenko <at> gmail.com> writes:
I could reproduce it. Seems to be like a problem in locate-file,
reproducible with
(let ((default-directory "/ssh::/bin"))
(locate-file ".." '("./")))
I'll dig further.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Sat, 13 May 2017 18:31:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 26911 <at> debbugs.gnu.org (full text, mbox):
> I could reproduce it. Seems to be like a problem in locate-file,
> reproducible with
>
> (let ((default-directory "/ssh::/bin"))
> (locate-file ".." '("./")))
>
> I'll dig further.
(cd "../") works (with a trailing slash).
Just to make it clear, as you've already pointed out, this is not specific to eshell:
cd and locate-file in files.el are also affected.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Mon, 15 May 2017 15:55:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 26911 <at> debbugs.gnu.org (full text, mbox):
Yegor Timoshenko <yegortimoshenko <at> gmail.com> writes:
Looks to me like a bug in Fexpand_file_name, which does not handle file
name handlers properly. Try
--8<---------------cut here---------------start------------->8---
(let ((default-directory "/ssh::/bin"))
(expand-file-name ".." "./"))
--8<---------------cut here---------------end--------------->8---
In fileio.c, lines 1393-1394, the following loop
--8<---------------cut here---------------start------------->8---
while (o != target && (--o, !IS_DIRECTORY_SEP (*o)))
continue;
--8<---------------cut here---------------end--------------->8---
replaces "/ssh:host:/bin/.." by "/ssh:host:". But it should be
"/ssh:host:/". I'm not such familiar with that code to fix it.
Best regards, Michael.
Added tag(s) confirmed.
Request was from
npostavs <at> users.sourceforge.net
to
control <at> debbugs.gnu.org.
(Sun, 28 May 2017 16:45:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Wed, 26 Aug 2020 20:41:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 26911 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I ran into the expand-file-name bug outside of Tramp, and fixed it by installing
the attached patch into Emacs master. I hope it fixes Bug#26911 too.
With luck it (or something like it) might even bear on Bug#34834 too, so I'll cc
this message there. (I don't use MS-Windows or Tramp so am not good at testing
in those environments.)
[0001-Fix-expand-file-name-symlink-to-dir-bug.patch (text/x-patch, attachment)]
Reply sent
to
Michael Albinus <michael.albinus <at> gmx.de>:
You have taken responsibility.
(Thu, 27 Aug 2020 11:47:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Yegor Timoshenko <yegortimoshenko <at> gmail.com>:
bug acknowledged by developer.
(Thu, 27 Aug 2020 11:47:02 GMT)
Full text and
rfc822 format available.
Message #24 received at 26911-done <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
Hi Paul,
> I ran into the expand-file-name bug outside of Tramp, and fixed it by
> installing the attached patch into Emacs master. I hope it fixes
> Bug#26911 too.
>
> With luck it (or something like it) might even bear on Bug#34834 too,
> so I'll cc this message there. (I don't use MS-Windows or Tramp so am
> not good at testing in those environments.)
I confirm it is fixed for bug#26911, so I close this bug.
Whether it is fixed also for bug#34384 I cannot check due to the lack of
an MS Windows machine.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Thu, 27 Aug 2020 18:33:01 GMT)
Full text and
rfc822 format available.
Message #27 received at 26911 <at> debbugs.gnu.org (full text, mbox):
No doubt the change (14fb657ba82) is fine in isolation, but now if Emacs is started from $HOME/somedir and I do find-file, the minibuffer prompt is "/home/mattias/somedir/" instead of "~/somedir/" which does not seem to be an improvement.
Worse, if cwd is $HOME, the minibuffer prompt becomes "~" instead of "~/" which is inconvenient since that slash has to be typed explicitly.
If nobody else is observing the effect then I'm doing something wrong but I'm not sure what.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Thu, 27 Aug 2020 18:39:02 GMT)
Full text and
rfc822 format available.
Message #30 received at 26911 <at> debbugs.gnu.org (full text, mbox):
> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Thu, 27 Aug 2020 20:31:59 +0200
> Cc: Michael Albinus <michael.albinus <at> gmx.de>, 26911 <at> debbugs.gnu.org,
> Eli Zaretskii <eliz <at> gnu.org>,
> Yegor Timoshenko <yegortimoshenko <at> gmail.com>
>
> If nobody else is observing the effect then I'm doing something wrong but I'm not sure what.
I see it as well, FWIW.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Thu, 27 Aug 2020 18:56:01 GMT)
Full text and
rfc822 format available.
Message #33 received at 26911 <at> debbugs.gnu.org (full text, mbox):
On Thu, 27 Aug 2020 21:38:10 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Mattias Engdegård <mattiase <at> acm.org>
>> Date: Thu, 27 Aug 2020 20:31:59 +0200
>> Cc: Michael Albinus <michael.albinus <at> gmx.de>, 26911 <at> debbugs.gnu.org,
>> Eli Zaretskii <eliz <at> gnu.org>,
>> Yegor Timoshenko <yegortimoshenko <at> gmail.com>
>>
>> If nobody else is observing the effect then I'm doing something wrong but
>> I'm not sure what.
>
> I see it as well, FWIW.
So do I.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Thu, 27 Aug 2020 21:55:01 GMT)
Full text and
rfc822 format available.
Message #36 received at 26911 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 8/27/20 11:31 AM, Mattias Engdegård wrote:
> No doubt the change (14fb657ba82) is fine in isolation, but now if Emacs is started from $HOME/somedir and I do find-file, the minibuffer prompt is "/home/mattias/somedir/" instead of "~/somedir/" which does not seem to be an improvement.
>
> Worse, if cwd is $HOME, the minibuffer prompt becomes "~" instead of "~/" which is inconvenient since that slash has to be typed explicitly.
Thanks for reporting that. Sigh, too often when I fix one bug in
expand-file-name I introduce another. I installed the attached patch to fix this
bug (I and I hope it doesn't introduce yet another :-).
[0001-Fix-recently-introduced-expand-file-name-bug.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Fri, 28 Aug 2020 06:40:01 GMT)
Full text and
rfc822 format available.
Message #39 received at 26911 <at> debbugs.gnu.org (full text, mbox):
> Cc: Michael Albinus <michael.albinus <at> gmx.de>, 26911 <at> debbugs.gnu.org,
> Eli Zaretskii <eliz <at> gnu.org>, Yegor Timoshenko <yegortimoshenko <at> gmail.com>
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Thu, 27 Aug 2020 14:53:52 -0700
>
> Thanks for reporting that. Sigh, too often when I fix one bug in
> expand-file-name I introduce another. I installed the attached patch to fix this
> bug (I and I hope it doesn't introduce yet another :-).
Two tests (including the new one) fail here on MS-Windows:
Test fileio-tests--HOME-trailing-slash backtrace:
signal(ert-test-failed (((should (equal (expand-file-name "~") (expa
ert-fail(((should (equal (expand-file-name "~") (expand-file-name ho
(if (unwind-protect (setq value-197 (apply fn-195 args-196)) (setq f
(let (form-description-199) (if (unwind-protect (setq value-197 (app
(let ((value-197 'ert-form-evaluation-aborted-198)) (let (form-descr
(let* ((fn-195 #'equal) (args-196 (condition-case err (let ((signal-
(let ((home (car --dolist-tail--))) (setenv "HOME" home) (let* ((fn-
(while --dolist-tail-- (let ((home (car --dolist-tail--))) (setenv "
(let ((--dolist-tail-- '("/a/b/c" "/a/b/c/"))) (while --dolist-tail-
(let ((old-home (getenv "HOME"))) (let ((--dolist-tail-- '("/a/b/c"
(closure (t) nil (let ((old-home (getenv "HOME"))) (let ((--dolist-t
ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
ert-run-test(#s(ert-test :name fileio-tests--HOME-trailing-slash :do
ert-run-or-rerun-test(#s(ert--stats :selector (not ...) :tests [...
ert-run-tests((not (tag :unstable)) #f(compiled-function (event-type
ert-run-tests-batch((not (tag :unstable)))
ert-run-tests-batch-and-exit((not (tag :unstable)))
eval((ert-run-tests-batch-and-exit '(not (tag :unstable))) t)
command-line-1(("-L" ";." "-l" "ert" "-l" "src/fileio-tests.el" "--e
command-line()
normal-top-level()
Test fileio-tests--HOME-trailing-slash condition:
(ert-test-failed
((should
(equal
(expand-file-name "~")
(expand-file-name home)))
:form
(equal "d:/gnu/git/emacs/trunk/test/a/b/c/" "d:./a/b/c")
:value nil :explanation
(arrays-of-different-length 34 9 "d:/gnu/git/emacs/trunk/test/a/b/c/" "d:./a/b/c" first-mismatch-at 2)))
FAILED 1/12 fileio-tests--HOME-trailing-slash (0.000000 sec)
Test fileio-tests--expand-file-name-trailing-slash backtrace:
signal(ert-test-failed (((should (equal (expand-file-name fooslashal
ert-fail(((should (equal (expand-file-name fooslashalias "/") "/foo/
(if (unwind-protect (setq value-202 (apply fn-200 args-201)) (setq f
(let (form-description-204) (if (unwind-protect (setq value-202 (app
(let ((value-202 'ert-form-evaluation-aborted-203)) (let (form-descr
(let* ((fn-200 #'equal) (args-201 (condition-case err (let ((signal-
(let ((fooslashalias (car --dolist-tail--))) (let* ((fn-200 #'equal)
(while --dolist-tail-- (let ((fooslashalias (car --dolist-tail--)))
(let ((--dolist-tail-- '("foo/" "foo//" "foo/." "foo//." "foo///././
(closure (t) nil (let ((--dolist-tail-- '("foo/" "foo//" "foo/." "fo
ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
ert-run-test(#s(ert-test :name fileio-tests--expand-file-name-traili
ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
ert-run-tests((not (tag :unstable)) #f(compiled-function (event-type
ert-run-tests-batch((not (tag :unstable)))
ert-run-tests-batch-and-exit((not (tag :unstable)))
eval((ert-run-tests-batch-and-exit '(not (tag :unstable))) t)
command-line-1(("-L" ";." "-l" "ert" "-l" "src/fileio-tests.el" "--e
command-line()
normal-top-level()
Test fileio-tests--expand-file-name-trailing-slash condition:
(ert-test-failed
((should
(equal
(expand-file-name fooslashalias "/")
"/foo/"))
:form
(equal "d:/foo/" "/foo/")
:value nil :explanation
(arrays-of-different-length 7 5 "d:/foo/" "/foo/" first-mismatch-at 0)))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Fri, 28 Aug 2020 07:03:01 GMT)
Full text and
rfc822 format available.
Message #42 received at 26911 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 28 Aug 2020 09:39:38 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 26911 <at> debbugs.gnu.org, mattiase <at> acm.org, michael.albinus <at> gmx.de,
> yegortimoshenko <at> gmail.com
>
> > Cc: Michael Albinus <michael.albinus <at> gmx.de>, 26911 <at> debbugs.gnu.org,
> > Eli Zaretskii <eliz <at> gnu.org>, Yegor Timoshenko <yegortimoshenko <at> gmail.com>
> > From: Paul Eggert <eggert <at> cs.ucla.edu>
> > Date: Thu, 27 Aug 2020 14:53:52 -0700
> >
> > Thanks for reporting that. Sigh, too often when I fix one bug in
> > expand-file-name I introduce another. I installed the attached patch to fix this
> > bug (I and I hope it doesn't introduce yet another :-).
>
> Two tests (including the new one) fail here on MS-Windows:
I've now fixed most of the failures, but one still remains, and it
definitely seems to be due to the latest changes in expand-file-name,
note the "c:." part below:
Test fileio-tests--expand-file-name-trailing-slash backtrace:
signal(ert-test-failed (((should (equal (expand-file-name (concat "c
ert-fail(((should (equal (expand-file-name (concat "c:/" fooslashali
(if (unwind-protect (setq value-207 (apply fn-205 args-206)) (setq f
(let (form-description-209) (if (unwind-protect (setq value-207 (app
(let ((value-207 'ert-form-evaluation-aborted-208)) (let (form-descr
(let* ((fn-205 #'equal) (args-206 (condition-case err (let ((signal-
(progn (let* ((fn-200 #'equal) (args-201 (condition-case err (let ((
(if (memq system-type '(windows-nt ms-dos)) (progn (let* ((fn-200 #'
(let ((fooslashalias (car --dolist-tail--))) (if (memq system-type '
(while --dolist-tail-- (let ((fooslashalias (car --dolist-tail--)))
(let ((--dolist-tail-- '("foo/" "foo//" "foo/." "foo//." "foo///././
(closure (t) nil (let ((--dolist-tail-- '("foo/" "foo//" "foo/." "fo
ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
ert-run-test(#s(ert-test :name fileio-tests--expand-file-name-traili
ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
ert-run-tests((not (tag :unstable)) #f(compiled-function (event-type
ert-run-tests-batch((not (tag :unstable)))
ert-run-tests-batch-and-exit((not (tag :unstable)))
eval((ert-run-tests-batch-and-exit '(not (tag :unstable))) t)
command-line-1(("-L" ";." "-l" "ert" "-l" "src/fileio-tests.el" "--e
command-line()
normal-top-level()
Test fileio-tests--expand-file-name-trailing-slash condition:
(ert-test-failed
((should
(equal
(expand-file-name ...)
"c:/foo/"))
:form
(equal "c:./foo/" "c:/foo/")
:value nil :explanation
(arrays-of-different-length 8 7 "c:./foo/" "c:/foo/" first-mismatch-at 2)))
FAILED 5/12 fileio-tests--expand-file-name-trailing-slash (0.000000 sec)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Fri, 28 Aug 2020 10:49:01 GMT)
Full text and
rfc822 format available.
Message #45 received at 26911 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 28 Aug 2020 10:01:43 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 26911 <at> debbugs.gnu.org, mattiase <at> acm.org, michael.albinus <at> gmx.de,
> yegortimoshenko <at> gmail.com
>
> I've now fixed most of the failures, but one still remains, and it
> definitely seems to be due to the latest changes in expand-file-name,
> note the "c:." part below:
This is one symptom of a more general (and much more serious) problem
with the modified expand-file-name:
(expand-file-name "d:/foo/bar/../baz") => "d:./foo/baz"
That period after the colon following the drive letter shouldn't be
there. As you may imagine, many Emacs commands are now broken because
of this. This must be fixed ASAP.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Sat, 29 Aug 2020 05:53:02 GMT)
Full text and
rfc822 format available.
Message #48 received at 26911 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 8/28/20 3:48 AM, Eli Zaretskii wrote:
> That period after the colon following the drive letter shouldn't be
> there. As you may imagine, many Emacs commands are now broken because
> of this. This must be fixed ASAP.
I installed the attached patch to revert the recent expand-file-changes in the
DOS_NT case, which should fix the problem you mentioned.
This part of fileio.c is hard to follow because of the #ifdef DOS_NT and #ifdef
WINDOWSNT and #ifdef MSDOS and whatnot. How about if we move the
MS-Windows-specific code to a different source file instead of having that
forest of ifdefs in fileio.c? As things stand, it's hard to maintain the
mainline GNU code, because the way everything's arranged the Microsoft-specific
stuff significantly obfuscates everything else.
[0001-Revert-recent-expand-file-name-changes-if-DOS_NT.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Sat, 29 Aug 2020 06:32:01 GMT)
Full text and
rfc822 format available.
Message #51 received at 26911 <at> debbugs.gnu.org (full text, mbox):
> Cc: 26911 <at> debbugs.gnu.org, mattiase <at> acm.org, michael.albinus <at> gmx.de,
> yegortimoshenko <at> gmail.com
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Fri, 28 Aug 2020 22:52:28 -0700
>
> > That period after the colon following the drive letter shouldn't be
> > there. As you may imagine, many Emacs commands are now broken because
> > of this. This must be fixed ASAP.
>
> I installed the attached patch to revert the recent expand-file-changes in the
> DOS_NT case, which should fix the problem you mentioned.
Thanks, it does. But it produces a different problem:
(expand-file-name "." "c:/foo/bar/") => "c:/foo/bar
(note the absence of the trailing slash).
> This part of fileio.c is hard to follow because of the #ifdef DOS_NT and #ifdef
> WINDOWSNT and #ifdef MSDOS and whatnot. How about if we move the
> MS-Windows-specific code to a different source file instead of having that
> forest of ifdefs in fileio.c? As things stand, it's hard to maintain the
> mainline GNU code, because the way everything's arranged the Microsoft-specific
> stuff significantly obfuscates everything else.
Sorry, I'm not interested in messing with expand-file-name, as the
gains are insignificant, if there are any, and the potential problems
that could cause are a legion. I actually think that your latest set
of changes there was a mistake (for the same reasons), but as long as
you are prepared to fix the fallout, I won't actively object.
It took us a lot of blood, sweat, and tears to get to the point where
we are: that expand-file-name works correctly for all supported
systems (including DOS/Windows) and also the remote use case. We all
know how one of the gazillion use cases of that function can be easily
broken by a seemingly innocent change in its complex code. So I think
we should leave that function alone, and any problems with file names
(if they indeed are significant) should be fixed elsewhere.
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 29 Aug 2020 16:32:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Sat, 29 Aug 2020 16:47:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 26911 <at> debbugs.gnu.org (full text, mbox):
>> I installed the attached patch to revert the recent expand-file-changes in the
>> DOS_NT case, which should fix the problem you mentioned.
>
> Thanks, it does. But it produces a different problem:
>
> (expand-file-name "." "c:/foo/bar/") => "c:/foo/bar
>
> (note the absence of the trailing slash).
That's what Emacs 27 does on MS-Windows, no? So it's not a regression, and the
problem can be fixed at the convenience of whoever's interested in hacking on
the MS-Windows side of the code.
Another way to put it is that Bug#26911 is now fixed for GNU and POSIX, but not
for MS-Windows. My earlier changes attempted to fix it for all platforms, but
this had undesirable side-effects in MS-Windows so I withdrew the MS-Windows
part of the changes. I have therefore reopened Bug#26911 since I assume it's
still present on MS-Windows.
Are some of the new test cases failing on MS-Windows? Should I arrange for these
test cases to be expected to fail on MS-Windows? If so, please let me know which
ones are failing, so that I can do that.
> I'm not interested in messing with expand-file-name
That's understandable as expand-file-name is quite a mess internally. But if
you're not interested in any attempt to clean up the mess, I guess I should
refrain from giving it a shot.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Sat, 29 Aug 2020 17:01:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 26911 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
Hi Paul,
> Are some of the new test cases failing on MS-Windows? Should I arrange
> for these test cases to be expected to fail on MS-Windows? If so,
> please let me know which ones are failing, so that I can do that.
Maybe tramp-test05-expand-file-name fails now on MS-Windows. If somebody
could check it? If have no MS Windows machine to test.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Sat, 29 Aug 2020 18:28:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 26911 <at> debbugs.gnu.org (full text, mbox):
> Cc: 26911 <at> debbugs.gnu.org, mattiase <at> acm.org, michael.albinus <at> gmx.de,
> yegortimoshenko <at> gmail.com
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sat, 29 Aug 2020 09:46:29 -0700
>
> >> I installed the attached patch to revert the recent expand-file-changes in the
> >> DOS_NT case, which should fix the problem you mentioned.
> >
> > Thanks, it does. But it produces a different problem:
> >
> > (expand-file-name "." "c:/foo/bar/") => "c:/foo/bar
> >
> > (note the absence of the trailing slash).
>
> That's what Emacs 27 does on MS-Windows, no? So it's not a regression, and the
> problem can be fixed at the convenience of whoever's interested in hacking on
> the MS-Windows side of the code.
It's a regression wrt behavior on Posix platforms: it fails one of the
tests in fileio-tests.el:
Test fileio-tests--HOME-trailing-slash condition:
(ert-test-failed
((should
(equal
(expand-file-name "~")
(expand-file-name home)))
:form
(equal "c:/a/b/c" "c:/a/b/c/")
:value nil :explanation
(arrays-of-different-length 8 9 "c:/a/b/c" "c:/a/b/c/" first-mismatch-at 8)))
FAILED 1/12 fileio-tests--HOME-trailing-slash (0.000000 sec)
> Another way to put it is that Bug#26911 is now fixed for GNU and POSIX, but not
> for MS-Windows. My earlier changes attempted to fix it for all platforms, but
> this had undesirable side-effects in MS-Windows so I withdrew the MS-Windows
> part of the changes. I have therefore reopened Bug#26911 since I assume it's
> still present on MS-Windows.
If that is the case, I prefer that we revert all the changes made
recently to fix bug#26911, and leave that bug open, until a fix is
available that works on all platforms.
> > I'm not interested in messing with expand-file-name
>
> That's understandable as expand-file-name is quite a mess internally. But if
> you're not interested in any attempt to clean up the mess, I guess I should
> refrain from giving it a shot.
Fine with me, then let's revert the recent changes and go back to what
we had before.
Thanks for trying to fix that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Sat, 29 Aug 2020 18:30:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 26911 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 26911 <at> debbugs.gnu.org, mattiase <at> acm.org,
> yegortimoshenko <at> gmail.com
> Date: Sat, 29 Aug 2020 18:59:37 +0200
>
> Maybe tramp-test05-expand-file-name fails now on MS-Windows. If somebody
> could check it? If have no MS Windows machine to test.
I tried running "make tramp-tests", but all I get is this:
GEN lisp/net/tramp-tests.log
Not a Tramp file name: "NUL"
Any suggestions?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Sat, 29 Aug 2020 19:13:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 26911 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
>> Maybe tramp-test05-expand-file-name fails now on MS-Windows. If somebody
>> could check it? If have no MS Windows machine to test.
>
> I tried running "make tramp-tests", but all I get is this:
>
> GEN lisp/net/tramp-tests.log
> Not a Tramp file name: "NUL"
>
> Any suggestions?
Hmm, yes: on MS Windows, the mock trick doesn't work. I hoped, that at
least the tests which do not need a real connection do work.
Well, if you have a remote host reachable via putty, which has also a
/tmp directory, you could try
set REMOTE_TEMPORARY_FILE_DIRECTORY=/plink:user <at> host:/tmp
prior the make call.
Thanks, and best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Sat, 29 Aug 2020 19:32:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 26911 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: eggert <at> cs.ucla.edu, 26911 <at> debbugs.gnu.org, mattiase <at> acm.org,
> yegortimoshenko <at> gmail.com
> Date: Sat, 29 Aug 2020 21:12:30 +0200
>
> > I tried running "make tramp-tests", but all I get is this:
> >
> > GEN lisp/net/tramp-tests.log
> > Not a Tramp file name: "NUL"
> >
> > Any suggestions?
>
> Hmm, yes: on MS Windows, the mock trick doesn't work. I hoped, that at
> least the tests which do not need a real connection do work.
>
> Well, if you have a remote host reachable via putty, which has also a
> /tmp directory, you could try
>
> set REMOTE_TEMPORARY_FILE_DIRECTORY=/plink:user <at> host:/tmp
>
> prior the make call.
This variant seems to work:
REMOTE_TEMPORARY_FILE_DIRECTORY=/plink:user <at> host:/tmp make lisp/net/tramp-tests
Most of the tests are "skipped", but the one you were interested in
isn't skipped, and indeed fails:
Test tramp-test05-expand-file-name condition:
(ert-test-failed
((should
(string-equal
(expand-file-name "/method:host:/path/.")
(if ... "/method:host:/path/" "/method:host:/path")))
:form
(string-equal "/method:host:/path" "/method:host:/path/")
:value nil))
FAILED 12/70 tramp-test05-expand-file-name (0.000000 sec)
HTH
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Sat, 29 Aug 2020 20:43:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 26911 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 8/29/20 11:26 AM, Eli Zaretskii wrote:
>> That's what Emacs 27 does on MS-Windows, no? So it's not a regression, and the
>> problem can be fixed at the convenience of whoever's interested in hacking on
>> the MS-Windows side of the code.
>
> It's a regression wrt behavior on Posix platforms: it fails one of the
> tests in fileio-tests.el:
That's not a regression in the usual sense of the word, since Emacs master on
MS-Windows is behaving the same way it did in Emacs 27. It's merely a bug that
has been fixed on most platforms but not on MS-Windows.
The test you mentioned is newly-added and already special-cases for MS-Windows,
and it's easy to special-case it just a bit more. I installed the attached
little patch as a workaround until we can get the bug fixed in the MS-Windows
support code.
> If that is the case, I prefer that we revert all the changes made
> recently to fix bug#26911, and leave that bug open, until a fix is
> available that works on all platforms.
Although we should continue to leave the bug open (since it's still present on
MS-Windows), reverting would be the tail wagging the dog. We should not
reintroduce a bug on GNU and similar platforms merely because we haven't yet
found the time to fix the bug on MS-Windows.
It surely would be better to fix the bug on MS-Windows. A good way to start
doing that is to refactor the code a bit to avoid the tricky #ifdefs it
currently uses, as these #ifdefs make bugs like this painful to fix. I can draft
a patch along those lines if you like. I realize you're dubious about
refactoring and so wouldn't install the patch without checking with you.
If you prefer fixing it a different way of course feel free to suggest
something. Since I don't use MS-Windows your expertise would be helpful.
[0001-Mark-failing-fileio-test-on-MS-Windows.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Sun, 30 Aug 2020 09:48:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 26911 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
> This variant seems to work:
>
> REMOTE_TEMPORARY_FILE_DIRECTORY=/plink:user <at> host:/tmp make lisp/net/tramp-tests
>
> Most of the tests are "skipped", but the one you were interested in
> isn't skipped, and indeed fails:
>
> Test tramp-test05-expand-file-name condition:
> (ert-test-failed
> ((should
> (string-equal
> (expand-file-name "/method:host:/path/.")
> (if ... "/method:host:/path/" "/method:host:/path")))
> :form
> (string-equal "/method:host:/path" "/method:host:/path/")
> :value nil))
> FAILED 12/70 tramp-test05-expand-file-name (0.000000 sec)
This is as expected, thanks.
I'm a little bit undecided whether I do special-case the test for
running on MS Windows, or whether I wait that it will be fixed. WDYT?
> HTH
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Sun, 30 Aug 2020 14:11:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 26911 <at> debbugs.gnu.org (full text, mbox):
> Cc: 26911 <at> debbugs.gnu.org, mattiase <at> acm.org, michael.albinus <at> gmx.de,
> yegortimoshenko <at> gmail.com
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sat, 29 Aug 2020 13:42:23 -0700
>
> It surely would be better to fix the bug on MS-Windows. A good way to start
> doing that is to refactor the code a bit to avoid the tricky #ifdefs it
> currently uses, as these #ifdefs make bugs like this painful to fix. I can draft
> a patch along those lines if you like. I realize you're dubious about
> refactoring and so wouldn't install the patch without checking with you.
It isn't right for us to make significant changes in expand-file-name,
let alone refactor it. Its code is complex and full of subtle dark
corners, many of which are not well covered by our test suite.
Refactoring it into something more elegant is a large job -- for a
very small gain, since the function does its job 99.99% of the time.
We would be wasting our sparse resources if we do any serious changes
there, and will almost certainly introduce quite a few bugs on the
way.
It isn't worth it, definitely not in order to fix the couple of rare
bugs we are facing.
Instead, we should fix these particular bugs by localized changes
whose effect is limited to the specific situations we need to fix.
So with that in mind, let's please go back to the problems we have and
see how they can be fixed without unnecessary refactoring.
The original problem in this bug report was identified by Michael:
> In fileio.c, lines 1393-1394, the following loop
>
> --8<---------------cut here---------------start------------->8---
> while (o != target && (--o, !IS_DIRECTORY_SEP (*o)))
> continue;
> --8<---------------cut here---------------end--------------->8---
>
> replaces "/ssh:host:/bin/.." by "/ssh:host:". But it should be
> "/ssh:host:/".
Actually, IMO the problem is immediately following the above snippet:
/* Keep initial / only if this is the whole name. */
if (o == target && IS_ANY_SEP (*o) && p[3] == 0)
++o;
This is very easy to fix without affecting any other uses of the
function: we should consider one other case in addition to "only if /
is the whole name" -- the case where this fails to DTRT with remote
directories.
In your log message you alluded to another use case, unrelated to
remote file names, but didn't provide any details. Can you please
provide them now? Is that other use case really similar to the one
which started this bug report (if not, no need to fix them both
together)?
The related bug#34834 is again about remote file names, but it's a
different situation. AFAICT, it should also be easy to fix in a
localized manner.
Making such localized changes will allow us to be certain we don't
break any use cases we already support successfully.
Finally, I see no reason to require expand-file-name to preserve the
trailing slash -- we never required this until now, and AFAIK had no
problems with that. If some specialized use case does need this, I'd
prefer to fix that only where and when it really matters. For
example, if some Eshell command needs it, let's first consider fixing
that in Eshell.
In any case, the trailing slash issue is only tangentially related to
the bugs discussed here, so let's not mix these separate issues.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Sun, 30 Aug 2020 14:15:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 26911 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: eggert <at> cs.ucla.edu, 26911 <at> debbugs.gnu.org, mattiase <at> acm.org,
> yegortimoshenko <at> gmail.com
> Date: Sun, 30 Aug 2020 11:46:53 +0200
>
> > Test tramp-test05-expand-file-name condition:
> > (ert-test-failed
> > ((should
> > (string-equal
> > (expand-file-name "/method:host:/path/.")
> > (if ... "/method:host:/path/" "/method:host:/path")))
> > :form
> > (string-equal "/method:host:/path" "/method:host:/path/")
> > :value nil))
> > FAILED 12/70 tramp-test05-expand-file-name (0.000000 sec)
>
> This is as expected, thanks.
>
> I'm a little bit undecided whether I do special-case the test for
> running on MS Windows, or whether I wait that it will be fixed. WDYT?
IMO, special-casing a test is only a good idea if that is done for
reasons unrelated to the behavior being tested. It makes no sense to
me to special-case a test in order to make failure look like success.
It's a slippery slope: once we go that way, before long we will have
to special-case real code, where the problematic behavior matters.
There's no real reason to special-case Windows in this case, because
its behavior doesn't really differ that much from Posix. There's a
small difference in syntax, but the concepts are all the same.
We should fix this, not paper over it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Sun, 30 Aug 2020 21:40:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 26911 <at> debbugs.gnu.org (full text, mbox):
On 8/30/20 7:09 AM, Eli Zaretskii wrote:
> you alluded to another use case, unrelated to
> remote file names, but didn't provide any details.
Here's an example. On RHEL 7.8 (file-symlink-p "/bin/.") returned "usr/bin"
which was a bug since "/bin/." is not (and cannot possibly be) a symbolic link.
This bug occurred because file-symlink-p calls expand-file-name which
incorrectly stripped trailing "/." from the file name before checking the file's
status. This sort of behavior broke code in startup.el that used file-attributes
(which had the same bug) to compare $PWD to the working directory's name, which
is how I ran into the bug again. (I vaguely recall running into this bug earlier
but lacked time/energy then to track it down and fix it.)
> Is that other use case really similar to the one
> which started this bug report
I expect they're related if we look at the mess inside file-attributes. They may
not appear to be similar to users who don't know how Emacs is implemented.
> I see no reason to require expand-file-name to preserve the
> trailing slash
It's required because trailing slash affects how file names are interpreted on
GNU and other POSIXish platforms. Emacs should not second-guess GNU and POSIX on
this: it should interpret file names like the underlying platforms do, as
anything else would be unnecessarily confusing.
> IMO the problem is immediately following the above snippet:
>
> /* Keep initial / only if this is the whole name. */
> if (o == target && IS_ANY_SEP (*o) && p[3] == 0)
> ++o;
>
> This is very easy to fix without affecting any other uses of the
> function: we should consider one other case in addition to "only if /
> is the whole name" -- the case where this fails to DTRT with remote
> directories.
Such a fix should be no problem for the GNU/POSIXish side, as that snippet is in
the DOS_NT code and any fixes there should affect only MS-Windows and DOS. I
don't know what a "remote directory" is in that context, though, so I can't give
specific advice.
> Its code is complex and full of subtle dark
> corners, many of which are not well covered by our test suite.
expand-file-name is more complex than it needs to be, and its dark corners would
be less dark if we cleaned it up a bit. In refactoring I would not attempt
elegance, only understandability. Right now the code is needlessly hard to
understand, and that makes it hard to fix - something I encountered while trying
to fix some of the abovementioned bugs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Mon, 31 Aug 2020 14:59:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 26911 <at> debbugs.gnu.org (full text, mbox):
> Cc: 26911 <at> debbugs.gnu.org, mattiase <at> acm.org, michael.albinus <at> gmx.de,
> yegortimoshenko <at> gmail.com
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sun, 30 Aug 2020 14:39:28 -0700
>
> This bug occurred because file-symlink-p calls expand-file-name which
> incorrectly stripped trailing "/." from the file name before checking the file's
> status.
It is not expand-file-name's job to know about these subtleties.
expand-file-name deals only with the syntax of file names. It doesn't
know anything about the semantics of "." and ".." except that they can
be removed to bring the file name to a standard form. It doesn't know
whether a file is a directory or a symlink or something else; it
doesn't even care if the file exists. It isn't supposed to hit the
disk for its job.
It is therefore perfectly valid for it to remove the trailing "/."
without appending a slash. If file-symlink-p needs to handle such
file names specially, it should do it in its own code.
So this job should not be imposed on expand-file-name, and we should
remove the code added for that purpose.
> > I see no reason to require expand-file-name to preserve the
> > trailing slash
>
> It's required because trailing slash affects how file names are interpreted on
> GNU and other POSIXish platforms.
It is not the job of expand-file-name to interpret file names. Lisp
programs that need a directory's name to end in a slash should call
file-name-as-directory, this is why we have that function. If we
insist on appending the slash in all cases, then some code will
benefit, but other code will break (and will need to call
directory-file-name to avoid the breakage). There's no net win here,
so we should not do this, either.
expand-file-name is simply the wrong place for this kind of
functionality, even before we consider its complexity.
> > IMO the problem is immediately following the above snippet:
> >
> > /* Keep initial / only if this is the whole name. */
> > if (o == target && IS_ANY_SEP (*o) && p[3] == 0)
> > ++o;
> >
> > This is very easy to fix without affecting any other uses of the
> > function: we should consider one other case in addition to "only if /
> > is the whole name" -- the case where this fails to DTRT with remote
> > directories.
>
> Such a fix should be no problem for the GNU/POSIXish side, as that snippet is in
> the DOS_NT code and any fixes there should affect only MS-Windows and DOS. I
> don't know what a "remote directory" is in that context, though, so I can't give
> specific advice.
You are talking about the code after your changes, whereas I (and
Michael at the time he wrote that) were talking about the code before
your changes: then the above snippet affected all platforms.
> Right now the code is needlessly hard to understand, and that makes
> it hard to fix - something I encountered while trying to fix some of
> the abovementioned bugs.
It isn't hard for me to understand the current code, although it is
indeed complex (because the job it does is not trivial). But the
problem is not the complexity, the problem starts when we make changes
there which are either not strictly necessary, or affect more use
cases than the few we need to fix.
That function works, and works well. Let's not make it less
dependable than it is today.
Anyway, I think I understand all the issues now, so I will work on
fixing them soon in a way that will avoid unnecessary fallout.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Mon, 31 Aug 2020 18:16:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 26911 <at> debbugs.gnu.org (full text, mbox):
On 8/31/20 7:58 AM, Eli Zaretskii wrote:
> expand-file-name deals only with the syntax of file names.
Yes, but it does so under constraints imposed by semantics. This is why
expand-file-name can't simply remove *all* slashes from file names (which would
be just a "syntax" thing, no? :-).
On GNU and other POSIXish systems, expand-file-names is entitled to do its
syntactic manipulations only because because of the POSIX rules that "." means
the working directory, leading "/" means the file name is absolute, trailing "/"
means the file name is that of a directory, and so forth.
expand-file-name can simplify "/./" to "/", even though it cannot always
simplify "/." to "" (and it cannot simply remove *all* slashes :-), because
expand-file-name's syntactic manipulations simplify the file name in a safe way
that does not change the file name's meaning. (This principle has one
well-documented exception for symbolic links that do not point to sibling
directories, but that does not overturn the principle elsewhere.)
> It is therefore perfectly valid for it to remove the trailing "/."
> without appending a slash.
Not at all. In many cases that would change the meaning of the file name, and
expand-file-name is not supposed to do that. On GNU and POSIXish platforms it is
valid to remove trailing "/." in some cases (e.g., "/foo//.") but it is
definitely not valid to do it in all cases.
> It is not the job of expand-file-name to interpret file names.
That depends on what one means by "interpret". It is the job of expand-file-name
to simplify file names under standard assumptions consistent with the underlying
platform's behavior. If a "simplification" would disagree with the behavior of
the underlying platform, that would cause needless confusion and
expand-file-name should not do that.
> Lisp programs that need a directory's name to end in a slash should call
> file-name-as-directory, this is why we have that function.
That is a separate point, and is not directly relevant to whether
expand-file-name should change a file name's meaning by removing slashes from it.
> If we insist on appending the slash in all cases
Nobody is insisting on that.
All I'm saying is that if the user has put a slash in a file name,
expand-file-name should not remove the slash if the removal would change the
file name's meaning. This is a simple principle that is easy to explain to
users. No other principle would make nearly as much sense.
>>> IMO the problem is immediately following the above snippet:
>>>
>>> /* Keep initial / only if this is the whole name. */
>>> if (o == target && IS_ANY_SEP (*o) && p[3] == 0)
>>> ++o;
>>>
>>> This is very easy to fix without affecting any other uses of the
>>> function: we should consider one other case in addition to "only if /
>>> is the whole name" -- the case where this fails to DTRT with remote
>>> directories.
>>
>> Such a fix should be no problem for the GNU/POSIXish side, as that snippet is in
>> the DOS_NT code and any fixes there should affect only MS-Windows and DOS. I
>> don't know what a "remote directory" is in that context, though, so I can't give
>> specific advice.
>
> You are talking about the code after your changes, whereas I (and
> Michael at the time he wrote that) were talking about the code before
> your changes: then the above snippet affected all platforms.
Feel free to alter the code to fix these bugs in a different way. However, I
expect any such fix will be simpler if starts with the current code (which fixes
the bugs on GNU and other POSIX hosts) instead of with the older code (which
does not).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Mon, 31 Aug 2020 18:57:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 26911 <at> debbugs.gnu.org (full text, mbox):
> Cc: 26911 <at> debbugs.gnu.org, mattiase <at> acm.org, michael.albinus <at> gmx.de,
> yegortimoshenko <at> gmail.com
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Mon, 31 Aug 2020 11:15:35 -0700
>
> On 8/31/20 7:58 AM, Eli Zaretskii wrote:
>
> > expand-file-name deals only with the syntax of file names.
>
> Yes, but it does so under constraints imposed by semantics. This is why
> expand-file-name can't simply remove *all* slashes from file names (which would
> be just a "syntax" thing, no? :-).
No, because a valid syntax of an absolute file name is to start with a
slash.
> > It is therefore perfectly valid for it to remove the trailing "/."
> > without appending a slash.
>
> Not at all.
We disagree. So any further argument is fruitless, because I will not
change my mind on this. I'm pretty sure I'm right because this
function never did anything different from what I describe, until very
recently.
> In many cases that would change the meaning of the file name, and
> expand-file-name is not supposed to do that.
Once again, the meaning of a file name is out of scope of
expand-file-name's job.
> Feel free to alter the code to fix these bugs in a different way. However, I
> expect any such fix will be simpler if starts with the current code
I intend to fix the specific bugs that were reported, and will try
very hard not to alter any other behavior, but my baseline is how
expand-file-name behaved before your changes, not how it behaves now
(which is wrong).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Mon, 31 Aug 2020 23:37:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 26911 <at> debbugs.gnu.org (full text, mbox):
On 8/31/20 11:56 AM, Eli Zaretskii wrote:
>>> expand-file-name deals only with the syntax of file names.
>> Yes, but it does so under constraints imposed by semantics. This is why
>> expand-file-name can't simply remove*all* slashes from file names (which would
>> be just a "syntax" thing, no? :-).
> No, because a valid syntax of an absolute file name is to start with a
> slash.
Ending with a slash is just as much syntax as starting with a slash is. The
meaning (absolute versus relative for starting slash, or directory versus file
for ending slash) is a consequence of the syntax in both cases. In neither case
should expand-file-name remove the slash, unless it can determine that removing
the slash does not change the meaning of the name (which it can do in some cases
but not in all).
> We disagree. So any further argument is fruitless
That's not a good way to resolve the disagreement. A better way is for me to see
what changes you make or plan to make to expand-file-name. If these changes
handle file names on GNU and POSIX platforms consistently with other GNU
applications, everything will be OK. It's possible we are simply
misunderstanding each other, after all.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Tue, 01 Sep 2020 02:34:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 26911 <at> debbugs.gnu.org (full text, mbox):
> Cc: 26911 <at> debbugs.gnu.org, mattiase <at> acm.org, michael.albinus <at> gmx.de,
> yegortimoshenko <at> gmail.com
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Mon, 31 Aug 2020 16:36:41 -0700
>
> > We disagree. So any further argument is fruitless
>
> That's not a good way to resolve the disagreement.
It's not the best one, but I don't see how else we could resolve such
a basic disagreement.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Thu, 03 Sep 2020 17:29:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 26911 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 31 Aug 2020 17:58:17 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 26911 <at> debbugs.gnu.org, mattiase <at> acm.org, michael.albinus <at> gmx.de,
> yegortimoshenko <at> gmail.com
>
> Anyway, I think I understand all the issues now, so I will work on
> fixing them soon in a way that will avoid unnecessary fallout.
Now done. I reverted most of the changes we've been discussing
lately, and instead installed a simpler change which fixes both this
bug and bug#34834, and doesn't affect any unrelated use cases.
Michael, I'd appreciate Tramp-related testing. I've ran the standard
tests from the test suite, but I'm sure you have more, including some
tests that are normally disabled.
I believe this bug and bug#34834 can now be closed.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Thu, 03 Sep 2020 17:44:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 26911 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
> Michael, I'd appreciate Tramp-related testing. I've ran the standard
> tests from the test suite, but I'm sure you have more, including some
> tests that are normally disabled.
Will do. I'm slow these days due to private issues, sorry.
> Thanks.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Fri, 04 Sep 2020 11:56:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 26911 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
> Michael, I'd appreciate Tramp-related testing. I've ran the standard
> tests from the test suite, but I'm sure you have more, including some
> tests that are normally disabled.
My ansible script has finished. 75 runs of tramp-tests.el with different
configurations, no error in tramp-test05-expand-file-name or
tramp-test05-expand-file-name-relative.
However, I haven't run it on MS Windows.
> I believe this bug and bug#34834 can now be closed.
Yes.
> Thanks.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Fri, 04 Sep 2020 12:26:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 26911 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: eggert <at> cs.ucla.edu, 26911 <at> debbugs.gnu.org, mattiase <at> acm.org,
> yegortimoshenko <at> gmail.com
> Date: Fri, 04 Sep 2020 13:55:24 +0200
>
> > Michael, I'd appreciate Tramp-related testing. I've ran the standard
> > tests from the test suite, but I'm sure you have more, including some
> > tests that are normally disabled.
>
> My ansible script has finished. 75 runs of tramp-tests.el with different
> configurations, no error in tramp-test05-expand-file-name or
> tramp-test05-expand-file-name-relative.
Thanks, that's good news.
> However, I haven't run it on MS Windows.
I did, but most of the tests are skipped. Can you teach me how to
enable them on MS-Windows? I can use PuTTY to connect to a remote
GNU/Linux machine where I have an account, if that is necessary.
Thanks.
> > I believe this bug and bug#34834 can now be closed.
>
> Yes.
Will do.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Fri, 04 Sep 2020 13:54:01 GMT)
Full text and
rfc822 format available.
Message #116 received at 26911 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
>> However, I haven't run it on MS Windows.
>
> I did, but most of the tests are skipped. Can you teach me how to
> enable them on MS-Windows? I can use PuTTY to connect to a remote
> GNU/Linux machine where I have an account, if that is necessary.
Well, first check whether you can connect the remote host in
question. Try it interactively:
C-x C-f /plink:user <at> host:/tmp
("user" and "host" at your taste). The connection shall not require a
password. Alternatively, if you have created a PuTTy session with name
"session", you could use instead "/plinkx:session:/tmp".
Then, according to my MS Windows blurb, run in a CMD window:
--8<---------------cut here---------------start------------->8---
> set REMOTE_TEMPORARY_FILE_DIRECTORY=/plink:user <at> host:/tmp
> %HOMEPATH%\Desktop\emacs-28.0.50\bin\emacs.exe -Q -batch -L X:\src\tramp\lisp -l X:\src\tramp\test\tramp-tests.el -f ert-run-tests-batch-and-exit
--8<---------------cut here---------------end--------------->8---
I have absolutely no build environment, just a downloaded Emacs tarfile
including binaries. Therefore, Tramp itself is mounted as share on the
X: drive.
In the test results, you will first see a line with the used remote
directory. tramp-test00-availability tells you whether the connection
can be established. It shall look like
--8<---------------cut here---------------start------------->8---
Remote directory: `/plink:user <at> host:/tmp'
passed 1/70 tramp-test00-availability (0.053776 sec)
--8<---------------cut here---------------end--------------->8---
If this doesn't happen, or the first test returns with PASSED (capital
letters), something fails. Pls show me the output then.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Fri, 04 Sep 2020 14:41:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 26911 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: eggert <at> cs.ucla.edu, 26911 <at> debbugs.gnu.org, mattiase <at> acm.org,
> yegortimoshenko <at> gmail.com
> Date: Fri, 04 Sep 2020 15:53:09 +0200
>
> > I did, but most of the tests are skipped. Can you teach me how to
> > enable them on MS-Windows? I can use PuTTY to connect to a remote
> > GNU/Linux machine where I have an account, if that is necessary.
>
> Well, first check whether you can connect the remote host in
> question. Try it interactively:
>
> C-x C-f /plink:user <at> host:/tmp
>
> ("user" and "host" at your taste). The connection shall not require a
> password. Alternatively, if you have created a PuTTy session with name
> "session", you could use instead "/plinkx:session:/tmp".
>
> Then, according to my MS Windows blurb, run in a CMD window:
>
> --8<---------------cut here---------------start------------->8---
> > set REMOTE_TEMPORARY_FILE_DIRECTORY=/plink:user <at> host:/tmp
> > %HOMEPATH%\Desktop\emacs-28.0.50\bin\emacs.exe -Q -batch -L X:\src\tramp\lisp -l X:\src\tramp\test\tramp-tests.el -f ert-run-tests-batch-and-exit
> --8<---------------cut here---------------end--------------->8---
OK, thanks. This worked. The results (see below) are mixed, but the
problems seem mostly to have something to do with the remote system,
not with Emacs.
The first 27 tests all passed. Then things went south, with all the
rest but the last 5 tests failing. The failures are pretty similar,
and can be divided into the following groups:
. (file-error "Method `plink' should specify both encoding and decoding command or an scp program")
. (file-error "Couldn't find command to check if file exists")
. (file-error "Tramp failed to connect. If this happens repeatedly, try `M-x tramp-cleanup-this-connection'")
The last error always followed the penultimate one. Usually, 3
"failed to connect" errors after each couldn't find command".
Several tests failed with other error messages:
. Test tramp-test17-insert-directory backtrace:
signal(wrong-type-argument ("listp sh:"))
. Test tramp-test32-shell-command-dont-erase-buffer condition:
(ert-test-failed
((should
(string-equal "barbaz
"
(buffer-string)))
:form
(string-equal "barbaz
" "bar")
:value nil))
. Test tramp-test33-environment-variables condition:
(ert-test-failed
((should
(string-equal
(format "%s,tramp:%s
" emacs-version tramp-version)
(funcall this-shell-command-to-string "echo ${INSIDE_EMACS:-bla}")))
:form
(string-equal "28.0.50,tramp:2.5.0-pre
" "")
:value nil))
Finally, the summary:
Ran 71 tests, 32 results as expected, 28 unexpected, 11 skipped (2020-09-04 17:27:32+0300, 1357.765625 sec)
28 unexpected results:
FAILED tramp-test17-insert-directory
FAILED tramp-test18-file-attributes
FAILED tramp-test19-directory-files-and-attributes
FAILED tramp-test20-file-modes
FAILED tramp-test21-file-links
FAILED tramp-test22-file-times
FAILED tramp-test23-visited-file-modtime
FAILED tramp-test26-file-name-completion
FAILED tramp-test27-load
FAILED tramp-test28-process-file
FAILED tramp-test29-start-file-process
FAILED tramp-test29-start-file-process-direct-async
FAILED tramp-test30-make-process
FAILED tramp-test30-make-process-direct-async
FAILED tramp-test31-interrupt-process
FAILED tramp-test32-shell-command
FAILED tramp-test32-shell-command-dont-erase-buffer
FAILED tramp-test33-environment-variables
FAILED tramp-test34-connection-local-variables
FAILED tramp-test34-explicit-shell-file-name
FAILED tramp-test35-exec-path
FAILED tramp-test35-remote-path
FAILED tramp-test36-vc-registered
FAILED tramp-test37-make-auto-save-file-name
FAILED tramp-test38-find-backup-file-name
FAILED tramp-test39-make-nearby-temp-file
FAILED tramp-test40-special-characters
FAILED tramp-test43-asynchronous-requests
11 skipped results:
SKIPPED tramp-test24-file-acl
SKIPPED tramp-test25-file-selinux
SKIPPED tramp-test33-environment-variables-and-port-numbers
SKIPPED tramp-test40-special-characters-with-ls
SKIPPED tramp-test40-special-characters-with-perl
SKIPPED tramp-test40-special-characters-with-stat
SKIPPED tramp-test41-utf8
SKIPPED tramp-test41-utf8-with-ls
SKIPPED tramp-test41-utf8-with-perl
SKIPPED tramp-test41-utf8-with-stat
SKIPPED tramp-test42-file-system-info
What can I do about the failed tests?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Fri, 04 Sep 2020 15:21:01 GMT)
Full text and
rfc822 format available.
Message #122 received at submit <at> debbugs.gnu.org (full text, mbox):
On September 4, 2020 5:40:36 PM GMT+03:00, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Michael Albinus <michael.albinus <at> gmx.de>
>> Cc: eggert <at> cs.ucla.edu, 26911 <at> debbugs.gnu.org, mattiase <at> acm.org,
>> yegortimoshenko <at> gmail.com
>> Date: Fri, 04 Sep 2020 15:53:09 +0200
>>
>> > I did, but most of the tests are skipped. Can you teach me how to
>> > enable them on MS-Windows? I can use PuTTY to connect to a remote
>> > GNU/Linux machine where I have an account, if that is necessary.
>>
>> Well, first check whether you can connect the remote host in
>> question. Try it interactively:
>>
>> C-x C-f /plink:user <at> host:/tmp
>>
>> ("user" and "host" at your taste). The connection shall not require a
>> password. Alternatively, if you have created a PuTTy session with
>name
>> "session", you could use instead "/plinkx:session:/tmp".
>>
>> Then, according to my MS Windows blurb, run in a CMD window:
>>
>> --8<---------------cut here---------------start------------->8---
>> > set REMOTE_TEMPORARY_FILE_DIRECTORY=/plink:user <at> host:/tmp
>> > %HOMEPATH%\Desktop\emacs-28.0.50\bin\emacs.exe -Q -batch -L
>X:\src\tramp\lisp -l X:\src\tramp\test\tramp-tests.el -f
>ert-run-tests-batch-and-exit
>> --8<---------------cut here---------------end--------------->8---
>
>OK, thanks. This worked. The results (see below) are mixed, but the
>problems seem mostly to have something to do with the remote system,
>not with Emacs.
>
>The first 27 tests all passed. Then things went south, with all the
>rest but the last 5 tests failing. The failures are pretty similar,
>and can be divided into the following groups:
>
>. (file-error "Method `plink' should specify both encoding and decoding
>command or an scp program")
>
> . (file-error "Couldn't find command to check if file exists")
>
>. (file-error "Tramp failed to connect. If this happens repeatedly,
>try `M-x tramp-cleanup-this-connection'")
>
>The last error always followed the penultimate one. Usually, 3
>"failed to connect" errors after each couldn't find command".
>
>Several tests failed with other error messages:
>
> . Test tramp-test17-insert-directory backtrace:
> signal(wrong-type-argument ("listp sh:"))
>
> . Test tramp-test32-shell-command-dont-erase-buffer condition:
> (ert-test-failed
> ((should
> (string-equal "barbaz
> "
> (buffer-string)))
> :form
> (string-equal "barbaz
> " "bar")
> :value nil))
>
> . Test tramp-test33-environment-variables condition:
> (ert-test-failed
> ((should
> (string-equal
> (format "%s,tramp:%s
> " emacs-version tramp-version)
> (funcall this-shell-command-to-string "echo
>${INSIDE_EMACS:-bla}")))
> :form
> (string-equal "28.0.50,tramp:2.5.0-pre
> " "")
> :value nil))
>
>Finally, the summary:
>
>Ran 71 tests, 32 results as expected, 28 unexpected, 11 skipped
>(2020-09-04 17:27:32+0300, 1357.765625 sec)
>
> 28 unexpected results:
> FAILED tramp-test17-insert-directory
> FAILED tramp-test18-file-attributes
> FAILED tramp-test19-directory-files-and-attributes
> FAILED tramp-test20-file-modes
> FAILED tramp-test21-file-links
> FAILED tramp-test22-file-times
> FAILED tramp-test23-visited-file-modtime
> FAILED tramp-test26-file-name-completion
> FAILED tramp-test27-load
> FAILED tramp-test28-process-file
> FAILED tramp-test29-start-file-process
> FAILED tramp-test29-start-file-process-direct-async
> FAILED tramp-test30-make-process
> FAILED tramp-test30-make-process-direct-async
> FAILED tramp-test31-interrupt-process
> FAILED tramp-test32-shell-command
> FAILED tramp-test32-shell-command-dont-erase-buffer
> FAILED tramp-test33-environment-variables
> FAILED tramp-test34-connection-local-variables
> FAILED tramp-test34-explicit-shell-file-name
> FAILED tramp-test35-exec-path
> FAILED tramp-test35-remote-path
> FAILED tramp-test36-vc-registered
> FAILED tramp-test37-make-auto-save-file-name
> FAILED tramp-test38-find-backup-file-name
> FAILED tramp-test39-make-nearby-temp-file
> FAILED tramp-test40-special-characters
> FAILED tramp-test43-asynchronous-requests
>
> 11 skipped results:
> SKIPPED tramp-test24-file-acl
> SKIPPED tramp-test25-file-selinux
> SKIPPED tramp-test33-environment-variables-and-port-numbers
> SKIPPED tramp-test40-special-characters-with-ls
> SKIPPED tramp-test40-special-characters-with-perl
> SKIPPED tramp-test40-special-characters-with-stat
> SKIPPED tramp-test41-utf8
> SKIPPED tramp-test41-utf8-with-ls
> SKIPPED tramp-test41-utf8-with-perl
> SKIPPED tramp-test41-utf8-with-stat
> SKIPPED tramp-test42-file-system-info
>
>What can I do about the failed tests?
Hold on, these problems might be due to some quota I've exceeded on the remote system. I'm unable to log in there, am trying to talk to the admins about that...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Fri, 04 Sep 2020 15:21:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Fri, 04 Sep 2020 16:00:02 GMT)
Full text and
rfc822 format available.
Message #128 received at submit <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
>> FAILED tramp-test43-asynchronous-requests
>
> Hold on, these problems might be due to some quota I've exceeded on the remote system. I'm unable to log in there, am trying to talk to the admins about that...
Will do. Just FTR, that test is tagged with :unstable, and it shouldn't
run yet outside my laptop. Since we don't use the Make machinery with
selectors, it isn't skipped on MS Windows.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Fri, 04 Sep 2020 16:00:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Fri, 04 Sep 2020 16:10:01 GMT)
Full text and
rfc822 format available.
Message #134 received at 26911 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
> OK, thanks. This worked. The results (see below) are mixed, but the
> problems seem mostly to have something to do with the remote system,
> not with Emacs.
That's often the case; otherwise I would trap the failed tests locally.
> What can I do about the failed tests?
Well, there is the macro tramp--test-instrument-test-case. Usually, any
test which needs more analysis shall be wrapped by this macro, plus the
verbosity. Like
(tramp--test-instrument-test-case 6
... test code ...
)
The test code is usually the whole code of a ert-deftest body, except
the initial skip-unless forms. It will generate debug messages, which
could be analyzed. Unfortunately, it is often only me who can read the
result.
The verbosity is the value set for tramp-verbose. Often, it is
sufficient to set it to 6 (debug sent commands, and the responses). In
problematic cases it can be up to 10; the debug messages will be huge then.
An undocumented feature is a verbosity greater 10 (say 11). This
triggers also traces for all function calls of tramp-* functions via
trace.el. Usually, I ask for this only when I'm desperated ...
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Fri, 04 Sep 2020 17:43:02 GMT)
Full text and
rfc822 format available.
Message #137 received at submit <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: bug-gnu-emacs <at> gnu.org, 26911 <at> debbugs.gnu.org, mattiase <at> acm.org,
> eggert <at> cs.ucla.edu, yegortimoshenko <at> gmail.com
> Date: Fri, 04 Sep 2020 17:59:15 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> Hi Eli,
>
> >> FAILED tramp-test43-asynchronous-requests
> >
> > Hold on, these problems might be due to some quota I've exceeded on the remote system. I'm unable to log in there, am trying to talk to the admins about that...
I'm talking to sysadmins to see how to overcome this problem, but in
case I cannot, how do I run the Tramp suite one test at a time? can
you show me an example command for that?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Fri, 04 Sep 2020 17:43:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Sat, 05 Sep 2020 08:35:01 GMT)
Full text and
rfc822 format available.
Message #143 received at submit <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
> I'm talking to sysadmins to see how to overcome this problem, but in
> case I cannot, how do I run the Tramp suite one test at a time? can
> you show me an example command for that?
# make tramp-tests SELECTOR='tramp-test05-expand-file-name'
See the test/README file for a discussion of SELECTOR.
> Thanks.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Sat, 05 Sep 2020 08:35:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Sat, 05 Sep 2020 11:19:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 26911 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: bug-gnu-emacs <at> gnu.org, 26911 <at> debbugs.gnu.org, mattiase <at> acm.org,
> eggert <at> cs.ucla.edu, yegortimoshenko <at> gmail.com
> Date: Sat, 05 Sep 2020 10:34:39 +0200
>
> > I'm talking to sysadmins to see how to overcome this problem, but in
> > case I cannot, how do I run the Tramp suite one test at a time? can
> > you show me an example command for that?
>
> # make tramp-tests SELECTOR='tramp-test05-expand-file-name'
Thanks. FTR, this translates into the following invocation from the
shell prompt:
emacs -Q -batch -l test\lisp\net\tramp-tests.elc --eval "(ert-run-tests-batch-and-exit 'TEST-NAME)"
First, I think I know the reason for the problem I had yesterday to
run all the tests. There's some problem in the Tramp tests that
causes almost each test that was run to leave 3 processes on the
remote system: 2 sshd's and 1 /bin/sh. AFAICT, these are created by
the first connection made by each test. Most tests create additional
connections, but their processes are all killed or exit when the test
completes, whereas this one connection is left behind. And some test
leave behind more than one such triplet. So after running enough
tests, the system is full of these triplets of zombie processes, and
on a resource-challenged system that could cause additional
connections to fail due to lack of resources to start another process.
Is it possible to make sure these processes are killed as part of each
test's cleanup? For now, I ran the tests one by one, each time
killing the zombie processes manually on the remote system. It took
some time...
Anyway, doing this cleanup manually allowed me to run all the tests
(skipping those which I knew to be "unstable"), and all but one of
them succeeded. The one which failed is shown below together with the
failure description:
Test tramp-test30-make-process condition:
(ert-test-failed
((should
(string-match
(if ... "unknown signal
\\'" "killed.*
\\'")
(buffer-string)))
:form
(string-match "unknown signal
\\'" "killed
")
:value nil))
FAILED 1/1 tramp-test30-make-process (39.250000 sec)
Just to be sure, I've ran this test twice, and each time it failed
with the same error.
I think this more or less concludes the testing of the fixes in these
two bugs, so I'm going to close them now.
Thanks.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Sat, 05 Sep 2020 11:33:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Yegor Timoshenko <yegortimoshenko <at> gmail.com>:
bug acknowledged by developer.
(Sat, 05 Sep 2020 11:33:02 GMT)
Full text and
rfc822 format available.
Message #154 received at 26911-done <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 05 Sep 2020 14:18:30 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 26911 <at> debbugs.gnu.org, mattiase <at> acm.org, eggert <at> cs.ucla.edu,
> yegortimoshenko <at> gmail.com
>
> I think this more or less concludes the testing of the fixes in these
> two bugs, so I'm going to close them now.
Done.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Sat, 05 Sep 2020 15:59:02 GMT)
Full text and
rfc822 format available.
Message #157 received at 26911 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
> First, I think I know the reason for the problem I had yesterday to
> run all the tests. There's some problem in the Tramp tests that
> causes almost each test that was run to leave 3 processes on the
> remote system: 2 sshd's and 1 /bin/sh. AFAICT, these are created by
> the first connection made by each test. Most tests create additional
> connections, but their processes are all killed or exit when the test
> completes, whereas this one connection is left behind. And some test
> leave behind more than one such triplet. So after running enough
> tests, the system is full of these triplets of zombie processes, and
> on a resource-challenged system that could cause additional
> connections to fail due to lack of resources to start another process.
>
> Is it possible to make sure these processes are killed as part of each
> test's cleanup? For now, I ran the tests one by one, each time
> killing the zombie processes manually on the remote system. It took
> some time...
Most of the tests start with (skip-unless (tramp--test-enabled)). This
defun calls tramp-cleanup-connection, which shall also kill all related
Tramp processes. Doesn't seem to work on MS Windows.
Hard to debug for me w/o such a machine. Could you write a bug report as
a reminder for me, that I investigate when I have such a machine?
> Anyway, doing this cleanup manually allowed me to run all the tests
> (skipping those which I knew to be "unstable"), and all but one of
> them succeeded. The one which failed is shown below together with the
> failure description:
>
> Test tramp-test30-make-process condition:
> (ert-test-failed
> ((should
> (string-match
> (if ... "unknown signal
> \\'" "killed.*
> \\'")
> (buffer-string)))
> :form
> (string-match "unknown signal
> \\'" "killed
> ")
> :value nil))
> FAILED 1/1 tramp-test30-make-process (39.250000 sec)
>
> Just to be sure, I've ran this test twice, and each time it failed
> with the same error.
Hahh! There is a special case in that test for MS-Windows:
--8<---------------cut here---------------start------------->8---
(should
(string-match
(if (eq system-type 'windows-nt)
"unknown signal\n\\'" "killed.*\n\\'")
(buffer-string))))
--8<---------------cut here---------------end--------------->8---
IIRC, somebody has reported this different return message. Or maybe I
have seen this on the MS Windows machine I've used for testing.
Maybe we shall simply allow both messages, because the exact wording
doesn't matter. What about the appended patch?
> Thanks.
Best regards, Michael.
[Message part 2 (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Sat, 05 Sep 2020 16:34:02 GMT)
Full text and
rfc822 format available.
Message #160 received at 26911 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: 26911 <at> debbugs.gnu.org, mattiase <at> acm.org, eggert <at> cs.ucla.edu,
> yegortimoshenko <at> gmail.com
> Date: Sat, 05 Sep 2020 17:57:56 +0200
>
> > Is it possible to make sure these processes are killed as part of each
> > test's cleanup? For now, I ran the tests one by one, each time
> > killing the zombie processes manually on the remote system. It took
> > some time...
>
> Most of the tests start with (skip-unless (tramp--test-enabled)). This
> defun calls tramp-cleanup-connection, which shall also kill all related
> Tramp processes. Doesn't seem to work on MS Windows.
AFAICS, tramp-cleanup-connection deletes the network connection
processes, but is that supposed to make sure the other side of the
connection exits cleanly?
> Hard to debug for me w/o such a machine. Could you write a bug report as
> a reminder for me, that I investigate when I have such a machine?
Will do. And let me know if I can provide more details about this
matter, or help you debug this.
> > Test tramp-test30-make-process condition:
> > (ert-test-failed
> > ((should
> > (string-match
> > (if ... "unknown signal
> > \\'" "killed.*
> > \\'")
> > (buffer-string)))
> > :form
> > (string-match "unknown signal
> > \\'" "killed
> > ")
> > :value nil))
> > FAILED 1/1 tramp-test30-make-process (39.250000 sec)
> >
> > Just to be sure, I've ran this test twice, and each time it failed
> > with the same error.
>
> Hahh! There is a special case in that test for MS-Windows:
>
> --8<---------------cut here---------------start------------->8---
> (should
> (string-match
> (if (eq system-type 'windows-nt)
> "unknown signal\n\\'" "killed.*\n\\'")
> (buffer-string))))
> --8<---------------cut here---------------end--------------->8---
>
> IIRC, somebody has reported this different return message. Or maybe I
> have seen this on the MS Windows machine I've used for testing.
>
> Maybe we shall simply allow both messages, because the exact wording
> doesn't matter. What about the appended patch?
It fixes the problem, thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Sat, 05 Sep 2020 17:09:01 GMT)
Full text and
rfc822 format available.
Message #163 received at 26911 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 05 Sep 2020 19:33:27 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 26911 <at> debbugs.gnu.org, mattiase <at> acm.org, eggert <at> cs.ucla.edu,
> yegortimoshenko <at> gmail.com
>
> > Hard to debug for me w/o such a machine. Could you write a bug report as
> > a reminder for me, that I investigate when I have such a machine?
>
> Will do.
Bug#43226.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Sat, 05 Sep 2020 17:37:01 GMT)
Full text and
rfc822 format available.
Message #166 received at 26911 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
>> Most of the tests start with (skip-unless (tramp--test-enabled)). This
>> defun calls tramp-cleanup-connection, which shall also kill all related
>> Tramp processes. Doesn't seem to work on MS Windows.
>
> AFAICS, tramp-cleanup-connection deletes the network connection
> processes, but is that supposed to make sure the other side of the
> connection exits cleanly?
It does at least when you're on GNU/Linux. What happens on MS Windows is
beyond my knowledge.
Perhaps I'll call process-send-eof prior killing the process?
>> Maybe we shall simply allow both messages, because the exact wording
>> doesn't matter. What about the appended patch?
>
> It fixes the problem, thanks.
Pushed to master.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#26911; Package
emacs.
(Sat, 05 Sep 2020 17:57:01 GMT)
Full text and
rfc822 format available.
Message #169 received at 26911 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: 26911 <at> debbugs.gnu.org, mattiase <at> acm.org, eggert <at> cs.ucla.edu,
> yegortimoshenko <at> gmail.com
> Date: Sat, 05 Sep 2020 19:36:34 +0200
>
> > AFAICS, tramp-cleanup-connection deletes the network connection
> > processes, but is that supposed to make sure the other side of the
> > connection exits cleanly?
>
> It does at least when you're on GNU/Linux. What happens on MS Windows is
> beyond my knowledge.
Indeed, it's strange that the result should depend on the local
system, since the commands sent to the remote are the same in boths
cases, I'd imagine.
> Perhaps I'll call process-send-eof prior killing the process?
If you show me a patch, I can try it. But let's continue discussing
this in the bug I filed, bug#43226.
Thanks.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 04 Oct 2020 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 198 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.