Re: tramp (2.3.1-pre); Can't open file due to wrong local path under MS-Windows

2016-09-19 Thread Chris Zheng
From: Michael Albinus 
Subject: Re: tramp (2.3.1-pre); Can't open file due to wrong local path under 
MS-Windows
Date: Mon, 19 Sep 2016 14:32:53 +0200


Hello Michael,

> Hi Chris,
> 
>> With Tramp in master branch of Emacs, I can't open file through
>> "/sshx:" under MS-Windows. The recipe starting from "emacs -Q" looks
>> like:
>>
>> C-x C-f /sshx:r...@xxx.xxx.xxx.xx#x:/root/htpasswd.py RET
> 
> It took me a while to reproduce. The usual test cases don't show up this 
> error.
> 
>> The related messages look like:
>>
>> Tramp: Inserting ‘/sshx:r...@xxx.xxx.xxx.xx#x:/root/htpasswd.py’...
>> Tramp: Encoding remote file 
>> ‘/sshx:r...@xxx.xxx.xxx.xx#x:/root/htpasswd.py’ with ‘base64 <%s’...done
>> Tramp: Decoding local file ‘z:/TEMP/tramp.16808GLL.py’ with 
>> ‘base64-decode-region’...done
>> Tramp: Inserting ‘/sshx:r...@xxx.xxx.xxx.xx#x:/root/htpasswd.py’...failed
>> Removing old name: No such file or directory, /TEMP/tramp.16808GLL.py
> 
> Well, you have your temporary directory at z:/TEMP. Per default (at
> least in the environment I could use for test), it is C:/Temp or
> C:/Users/USER/AppData/Local/Temp or so.
> 
> Since "/Temp" is the same directory as "C:/Temp" in Emacs, the problem
> didn't appear to the tests.

I didn't notice this. Maybe this is the cause of the bug. And indeed
in another bug report
(http://misohena.jp/blog/2016-04-23-tramp-error-because-expand-file-name-and-cygwin-drive.html,
in Japanese) the temporary directory is also nonstandard.

>> I think the problem is due to the commit
>>
>> c5f466db6f6b8196b8429db8bb7b74f8090d5d3e
>> Fix Bug#20821
>>
>> * lisp/net/tramp.el (tramp-file-name-handler):
>> * lisp/net/tramp-sh.el (tramp-sh-handle-expand-file-name):
>> Use `tramp-drop-volume-letter'.  (Bug#20821)
>>
>> Since the volume letter ("z:") is dropped, the path becomes wrong. I
>> have read the original report of Bug#20821, but have no idea why the
>> `tramp-drop-volume-letter' was used here. Comment out the first call
>> to `tramp-drop-volume-letter' in `tramp-sh-handle-expand-file-name'
>> did fix the problem for me. Could you please have a look on it?
> 
> I've checked the whole story of that bug. The first change in
> `tramp-file-name-handler' is still needed for fixing the bug. But as
> you've said, calling `tramp-drop-volume-letter' in
> `tramp-sh-handle-expand-file-name' is not needed anymore. I don't recall
> why I have applied it that time; maybe it was also needed, and it is now
> superfluous due to other changes in Tramp.
> 
> Anyway, I have removed that call as proposed by you, committed to the
> repositories. Could you, pls, check?

It is fixed for me. Thank you very much. And I will call others to test.

>> With many thanks,
>>
>> Chris
> 
> Best regards, Michael.

Regards,

Chris
___
Tramp-devel mailing list
Tramp-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/tramp-devel


Re: Is quotes in tramp-find-inline-compress needed in MS-Windows?

2018-02-02 Thread Chris Zheng

Hello Michael,

On Sat, 03 Feb 2018 05:29:40 +0800,
Michael Albinus wrote:
> 
> Hi Chris,
> 
> Thanks for the test. I've committed the appended patch to
> branch-2-3-stable in the Tramp repository, you might apply it locally.
> 
> Emacs 26.1 is already frozen in the repository, only patches for
> resolving newly introduced errors are accepted these days. So the fix
> must wait for Emacs 26.2.

Thank you for making Tramp better for MS-Windows users.

Regards,

Chris

> Best regards, Michael.

___
Tramp-devel mailing list
Tramp-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/tramp-devel


Is quotes in tramp-find-inline-compress needed in MS-Windows?

2018-02-01 Thread Chris Zheng

Hi all,

The function `tramp-find-inline-compress' in tramp-sh.el has the code:

(format
 ;; Windows shells need the program file name after
 ;; the pipe symbol be quoted if they use forward
 ;; slashes as directory separators.
 (if (memq system-type '(windows-nt))
 "echo %s | \"%s\" | \"%s\""
   "echo %s | %s | %s")
 magic compress decompress)

which says the commands need to be quoted in MS-Windows. But In
MS-Windows 8.1 I get

M-& echo xyzzy | gzip | gzip -d RET
⇒ Success.

M-& echo xyzzy | \"gzip\" | \"gzip -d\" RET
⇒ Error.

This makes me think is the quotes needed?

Thank you,

Chris

___
Tramp-devel mailing list
Tramp-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/tramp-devel


Re: Is quotes in tramp-find-inline-compress needed in MS-Windows?

2018-02-01 Thread Chris Zheng

On Fri, 02 Feb 2018 10:57:40 +0800,
Michael Albinus wrote:

Hello Michael,

> Chris Zheng <chriszhen...@gmail.com> writes:
> 
> 
> Hi Chris,
> 
> 
> The backslashes in the code snippet above are needed to mask the
> quotation mark in the string. They do not arrive the target shell. Try
> 
> M-& echo xyzzy | "gzip" | "gzip -d" RET

I thought about this command, and the results are

M-& echo xyzzy | "gzip" | "gzip -d" RET
⇒ Not a command error for "gzip -d".

M-& echo xyzzy | "gzip" | "gzip" -d RET
⇒ Success.

So the best approach is to quote only the program name. Thank you for
the reply and the clarification of backslashes. 

Best wishes,

Chris

> Best regards, Michael.

___
Tramp-devel mailing list
Tramp-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/tramp-devel


Re: The “//” fix confuses cygwin-mount

2018-03-26 Thread Chris Zheng
On Tue, 27 Mar 2018 06:47:37 +0800,
Michael Albinus wrote:

Hello Michael,

> Chris Zheng <chriszhen...@gmail.com> writes:
> 
> > Hello Michael,p
> 
> Hi Chris,
> 
> > It isn’t a Cygwin Emacs. It’s native compiled under Windows using
> > MSYS2 and MinGW-w64. I’m in master branch at
> 
> I've hijacked the laptop of my wife (Windows user), so I could reproduce
> the problem. Shall be fixed now, patch pushed to the repositories. Could
> you, pls test?

Yes. It is fixed.

Thank you very much,

Chris

___
Tramp-devel mailing list
Tramp-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/tramp-devel


Re: The “//” fix confuses cygwin-mount

2018-03-22 Thread Chris Zheng
On Fri, 23 Mar 2018 01:00:57 +0800,
Michael Albinus wrote:
> 
> Chris Zheng <chriszhen...@gmail.com> writes:
> 
> > Dear List,
> 
> Hi Chris,

Dear Michael,

> > The commit c24c5dc4a4cc18e7f1ec949efcfe1d4bae541d02 confuses the
> > cygwin-mount that serves the translation from “/c/Windows” to
> > “C:/Windows/” under MS-Windows. With the above commit and
> > cygwin-mount,
> >
> > (substitute-in-file-name "/method:host:/foo")
> > ⇒ "/method:host:c:/msys64/foo"
> 
> Thanks for the report. I've fixed this in both Tramp and Emacs repositories.

I’m sorry to tell you that the fix isn’t right, as

(tramp-drop-volume-letter "c:/msys64/foo") ⇒ "/msys64/foo"

which is still wrong. The “/msys64” should be removed, too.

> > Thank you very much,
> >
> > Chris
> 
> Best regards, Michael.

Thank you,

Chris

___
Tramp-devel mailing list
Tramp-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/tramp-devel


The “//” fix confuses cygwin-mount

2018-03-21 Thread Chris Zheng

Dear List,

The commit c24c5dc4a4cc18e7f1ec949efcfe1d4bae541d02 confuses the
cygwin-mount that serves the translation from “/c/Windows” to
“C:/Windows/” under MS-Windows. With the above commit and
cygwin-mount,

(substitute-in-file-name "/method:host:/foo")
⇒ "/method:host:c:/msys64/foo"

While before that commit the result is "/method:host:/foo".

The reason is that in ‘tramp-handle-substitute-in-file-name’ from
line 3563

(setq filename
  (concat (file-remote-p filename)
  (substitute-in-file-name localname))
  ^ (substitute-in-file-name "/foo") results in "c:/msys64/foo".

Previously the whole "/method:host:/foo" was translated by the
‘substitute-in-file-name’ thus no problem occurs.

Could you please have a look at this.

Thank you very much,

Chris

___
Tramp-devel mailing list
Tramp-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/tramp-devel


Re: The “//” fix confuses cygwin-mount

2018-03-23 Thread Chris Zheng
On Sat, 24 Mar 2018 05:17:46 +0800,
Michael Albinus wrote:

Hello Michael,

> Chris Zheng <chriszhen...@gmail.com> writes:
> 
> 
> Hi Chris,
> 
> > However, I observed that when I go to /scpx:E:/ with “C-x C-f”, and
> > “C-x C-f” again, the minibuffer shows “/scpx:E://”. Is this intended?
> 
> I cannot reproduce it, but I work on a GNU/Linux machine. Maybe it
> behaves different, compared to your MS Windows / cygwin run.
> 
> Or I misunderstand what you have said. Could you, pls, tell me the exact
> keystrokes which have led to this behavior?

Reproduction steps:

Suppose I want to connect to 222.222.222.222 with user kel.

1. emacs -Q

2. C-x C-f /scpx:kel@222.222.222.222:/ RET Then a dired buffer showing
the root directory is opened.

3. With cursor in the dired buffer, hit C-x C-f again.  I see the
minibuffer shows

“Find file: /scpx:kel@222.222.222.222://”.

I hit RET, the buffer is flashed, and the minibuffer shows

“Directory has changed on disk; type g to update Dired”.

If I go to other directory such as /bin, no double “//” is shown. I
have tested with two servers and the observation is identical.

I have to say that the problem isn’t serious, so feel free to ignore
it.

Thank you for your time.

> > Thank you,
> >
> > Chris
> 
> Best regards, Michael.

Best regards,

Chris

___
Tramp-devel mailing list
Tramp-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/tramp-devel


Re: The “//” fix confuses cygwin-mount

2018-03-24 Thread Chris Zheng
On Sat, 24 Mar 2018 07:10:04 +0800,
Michael Albinus wrote:

Hello Michael,

> Chris Zheng <chriszhen...@gmail.com> writes:
> 
> > Hello Michael,
> 
> Hi Chris,
> 
> > Reproduction steps:
> >
> > Suppose I want to connect to 222.222.222.222 with user kel.
> >
> > 1. emacs -Q
> >
> > 2. C-x C-f /scpx:kel@222.222.222.222:/ RET Then a dired buffer showing
> > the root directory is opened.
> >
> > 3. With cursor in the dired buffer, hit C-x C-f again.  I see the
> > minibuffer shows
> >
> > “Find file: /scpx:kel@222.222.222.222://”.
> 
> Strange. I cannot reproduce.
> 
> > I hit RET, the buffer is flashed, and the minibuffer shows
> >
> > “Directory has changed on disk; type g to update Dired”.
> 
> Even stranger. No need to tell this to you.

It seems that I saw this many times and I got used to it.

> > If I go to other directory such as /bin, no double “//” is shown. I
> > have tested with two servers and the observation is identical.
> >
> > I have to say that the problem isn’t serious, so feel free to ignore
> > it.
> 
> Well, at least I'm not nervous yet :-)
> 
> It is Cygwin Emacs, isn't it? Which version? Self compiled?

It isn’t a Cygwin Emacs. It’s native compiled under Windows using
MSYS2 and MinGW-w64. I’m in master branch at

011186279c  Port emacs-module-tests to 32-bit Emacs

Configuration options:
  --prefix=/mingw64 --without-imagemagick --without-dbus --with-modules 
'CFLAGS=-Ofast -fopt-info -g0 -mtune=native' 
PKG_CONFIG_PATH=/mingw64/lib/pkgconfig

> > Best regards,
> >
> > Chris
> 
> Best regards, Michael.

Chris "A Windows user"

___
Tramp-devel mailing list
Tramp-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/tramp-devel


Re: The “//” fix confuses cygwin-mount

2018-10-05 Thread Chris Zheng


Thank you, Michael and Andy. The fix is great.

___
Tramp-devel mailing list
Tramp-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/tramp-devel


Re: The “//” fix confuses cygwin-mount

2018-09-24 Thread Chris Zheng

Hello Michael,

I’m afraid the following commit is still needed for MS-Windows user
using cygwin-mount because this problem is return.

2849477af22a1e20a86da7743562495e00b3a1b7
Author: Michael Albinus 
AuthorDate: Thu Mar 22 16:52:58 2018 +0100
Commit: Michael Albinus 
CommitDate: Thu Mar 22 16:52:58 2018 +0100

For your reference, with current master of Emacs,

(substitute-in-file-name "/method:host:/foo") yields
"/method:host:c:/msys64/foo"

Thank you very much,

Chris

___
Tramp-devel mailing list
Tramp-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/tramp-devel