bug#18891: Doesn't handle pwd = /C: very well

bug#18891: Doesn't handle pwd = /C: very well

[Glenn Morris]

Package: emacs
Severity: minor
Version: 24.4

On a GNU/Linux system:

mkdir -p /C:
cd /C:
emacs-24.4 -Q

-> 
    
    Tramp: Opening connection for C using scp...
    Opening connection for C using scp... \
    Tramp: Sending command `exec ssh    -e none C'
    Tramp: Waiting for prompts from remote shell...
    Waiting for prompts from remote shell... \
    Tramp failed to connect.  If this happens repeatedly, try
        `M-x tramp-cleanup-this-connection'
[waits for ~ 30 seconds]
    Wrote /home/rgm/.emacs.d/tramp

and Emacs never actually starts.


cf: http://lists.gnu.org/archive/html/bug-gnu-emacs/2001-09/msg00154.html

bug#18891: Doesn't handle pwd = /C: very well

[Michael Albinus]

Glenn Morris <rgm@gnu.org> writes:

> On a GNU/Linux system:
>
> mkdir -p /C:
> cd /C:
> emacs-24.4 -Q
>
> ->
>
>     Tramp: Opening connection for C using scp...
>     Opening connection for C using scp... \
>     Tramp: Sending command `exec ssh    -e none C'
>     Tramp: Waiting for prompts from remote shell...
>     Waiting for prompts from remote shell... \
>     Tramp failed to connect.  If this happens repeatedly, try
>         `M-x tramp-cleanup-this-connection'
> [waits for ~ 30 seconds]
>     Wrote /home/rgm/.emacs.d/tramp
>
> and Emacs never actually starts.

1. The Lisp backtrace reads like this:

  ...
  apply(tramp-sh-file-name-handler expand-file-name ("/C:./." nil))
  tramp-file-name-handler(expand-file-name "/C:./." nil)
  file-attributes("/C:./.")
  normal-top-level()

   "/C:" as default directory is wrong. It triggers Tramp to start,
   which fails. Maybe one could prevent this problem by giving the
   default directory the prefix "/:".

2. If I wrap the call of `file-attributes' in `normal-top-level' with
   `ignore-errors', Emacs starts up after claiming the Tramp
   error. However, the docstring of `file-attributes' says "Value is nil
   if specified file cannot be opened.". Therefore, `file-attributes'
   itself must suppress errors even in such calls like

   dired.c:912:  filename = Fexpand_file_name (filename, Qnil);

3. The 30 sec delay is caused by Tramp, which tries to show the
   connection buffer in order to give the user the possibility to know
   what's up. This is not useful in this case, because Emacs hasn't
   started yet. I would like to suppress this pause at this stage;
   however I didn't find a way, how I could check whether Emacs is able
   to show a buffer to the user (startup finished). A hint for this kind
   of check would be helpful for me.

> cf: http://lists.gnu.org/archive/html/bug-gnu-emacs/2001-09/msg00154.html

13 years old ... it's time to fix it.

Best regards, Michael.

bug#18891: Doesn't handle pwd = /C: very well

[Glenn Morris]

Michael Albinus wrote:

>    "/C:" as default directory is wrong. It triggers Tramp to start,
>    which fails. Maybe one could prevent this problem by giving the
>    default directory the prefix "/:".

You know much more about this than I do, but my dumb idea was:
if a directory name happens to match a tramp pattern, as "/C:"
presumably does, how about first checking if a local directory literally
named that exists, before invoking a remote handler?

bug#18891: Doesn't handle pwd = /C: very well

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Tue, 04 Nov 2014 11:47:19 -0500
> Cc: 18891@debbugs.gnu.org
> 
> Michael Albinus wrote:
> 
> >    "/C:" as default directory is wrong. It triggers Tramp to start,
> >    which fails. Maybe one could prevent this problem by giving the
> >    default directory the prefix "/:".
> 
> You know much more about this than I do, but my dumb idea was:
> if a directory name happens to match a tramp pattern, as "/C:"
> presumably does, how about first checking if a local directory literally
> named that exists, before invoking a remote handler?

That's probably something Emacs should do _before_ invoking the
handler, no?  I mean, the decision whether to let the handler do this
job is outside the scope of the handler.

bug#18891: Doesn't handle pwd = /C: very well

[Glenn Morris]

Eli Zaretskii wrote:

>> if a directory name happens to match a tramp pattern, as "/C:"
>> presumably does, how about first checking if a local directory literally
>> named that exists, before invoking a remote handler?
>
> That's probably something Emacs should do _before_ invoking the
> handler, no?  I mean, the decision whether to let the handler do this
> job is outside the scope of the handler.

That's what I meant, I think...

bug#18891: Doesn't handle pwd = /C: very well

[Michael Albinus]

Glenn Morris <rgm@gnu.org> writes:

> Eli Zaretskii wrote:
>
>>> if a directory name happens to match a tramp pattern, as "/C:"
>>> presumably does, how about first checking if a local directory literally
>>> named that exists, before invoking a remote handler?
>>
>> That's probably something Emacs should do _before_ invoking the
>> handler, no?  I mean, the decision whether to let the handler do this
>> job is outside the scope of the handler.
>
> That's what I meant, I think...

There could be undesired side effects. File name handlers are invoked
only if the file *name* matches a corresponding regexp, nothing else. If
you want to make checks on the file system itself, it would result at
least in performance penalties.

Not to speak about cases where it is not possible.

(substitute-in-file-name "/C:/$FOO") requires the expansion of
$FOO. That's the task of Tramp, according to that file name. Nothing you
can check before invoking Tramp, because you don't know the value of $FOO.

Best regards, Michael.

bug#18891: Doesn't handle pwd = /C: very well

[Glenn Morris]

Michael Albinus wrote:

> There could be undesired side effects. File name handlers are invoked
> only if the file *name* matches a corresponding regexp, nothing else. If
> you want to make checks on the file system itself, it would result at
> least in performance penalties.
>
> Not to speak about cases where it is not possible.
>
> (substitute-in-file-name "/C:/$FOO") requires the expansion of
> $FOO. That's the task of Tramp, according to that file name. Nothing you
> can check before invoking Tramp, because you don't know the value of $FOO.

Well, it seems to me that so long as the Tramp file name syntax can also
match a real local file name, you cannot avoid testing for the existence
of such a file. If you are saying that needs to be done in Tramp rather
than before Tramp is invoked, fine by me.

bug#18891: Doesn't handle pwd = /C: very well

[Michael Albinus]

Glenn Morris <rgm@gnu.org> writes:

> Well, it seems to me that so long as the Tramp file name syntax can also
> match a real local file name, you cannot avoid testing for the existence
> of such a file. If you are saying that needs to be done in Tramp rather
> than before Tramp is invoked, fine by me.

*If* you don't want a file name handler being invoked, you can either
let-bind `file-name-handler-alist' to nil, or you could prepend the file
name by "/:", i.e. "/:/C:/" in the case which triggered the bug. Both is
possible in order to mask default-directory when starting up Emacs.

And a local file name which will be in conflict with such a file name
for Tramp will be extremely rare, I believe. Do there exist real life
reports?

And this bug (Emacs does not start) is triggered by `file-attributes'
implementation, which does not keep its promises (return nil when
FILENAME cannot be opened). I believe we shall fix this, instead of
changing basic design decisions.

Best regards, Michael.

bug#18891: Doesn't handle pwd = /C: very well

[Glenn Morris]

Michael Albinus wrote:

> There could be undesired side effects. File name handlers are invoked
> only if the file *name* matches a corresponding regexp, nothing else. If
> you want to make checks on the file system itself, it would result at
> least in performance penalties.

I don't consider a performance penalty an undesired side effect, but
rather necessary to avoid a completely incorrect result, such as we have
in this case.

> (substitute-in-file-name "/C:/$FOO") requires the expansion of
> $FOO. That's the task of Tramp, according to that file name. Nothing you
> can check before invoking Tramp, because you don't know the value of $FOO.

Why can't it be checked before Tramp?

What if "FOO = foo" in the local environment, and "/C:/foo"
is a real directory on the local machine?

bug#18891: Doesn't handle pwd = /C: very well

[Michael Albinus]

Glenn Morris <rgm@gnu.org> writes:

> I don't consider a performance penalty an undesired side effect, but
> rather necessary to avoid a completely incorrect result, such as we have
> in this case.

The "unnecessary result" is an error in `file-attributes'.

>> (substitute-in-file-name "/C:/$FOO") requires the expansion of
>> $FOO. That's the task of Tramp, according to that file name. Nothing you
>> can check before invoking Tramp, because you don't know the value of $FOO.
>
> Why can't it be checked before Tramp?
>
> What if "FOO = foo" in the local environment, and "/C:/foo"
> is a real directory on the local machine?

`substitute-in-file-name' is an operation supporting file name
handlers. This handler must be called, instead of expanding an
environment variable locally. That's the design, and the promise by the
API.

Everything could be changed, of course. But please then with a
corresponding *design* change. And `substitute-in-file-name' was just
the very first example which came to my mind, without thinking about
seriously. There are many other operations supporting file name
handlers, which must be investigated for this kind of changes as well.

For the records: I do not oppose fundamentally such changes. I just
resist to change something on-the-fly, without redesign.

Best regards, Michael.

bug#18891: Doesn't handle pwd = /C: very well

[Stefan Monnier]

> That's probably something Emacs should do _before_ invoking the
> handler, no?  I mean, the decision whether to let the handler do this
> job is outside the scope of the handler.

The jka-compr and epa handlers apply to files that are accessible
locally, so I don't think we can decide it before running the handler.


        Stefan

bug#18891: Doesn't handle pwd = /C: very well

[Michael Albinus]

Hi,

I've committed two patches to the emacs-24 branch, which should fix the
problem. Glenn, could you, please, check?

Thanks, and best regards, Michael.

bug#18891: Doesn't handle pwd = /C: very well

[Glenn Morris]

Michael Albinus wrote:

> I've committed two patches to the emacs-24 branch, which should fix the
> problem. Glenn, could you, please, check?

Well, Emacs starts now.
It still prints
    
    Tramp: Opening connection for C using scp...
    Opening connection for C using scp... \
    Tramp: Sending command `exec ssh    -e none C'
    Tramp: Waiting for prompts from remote shell...
    Waiting for prompts from remote shell... \
    Tramp: Waiting for prompts from remote shell...failed
    Tramp: Opening connection for C using scp...failed
    
in the terminal, and C-x C-f shows the prompt as the weird-looking:

    Find file: /:/C:/

but if that is how it has to be, so be it.

Trying to visit a new file fails though:

   C-x C-f bar RET

since it again tries to do something via Tramp and fails.

bug#18891: Doesn't handle pwd = /C: very well

[Glenn Morris]

PS this makes me think, what happens if the local file name happens to
match a remote host that does exist...

If as you say the design prefers remote hosts over local ones, that
seems like a bad design to me.

bug#18891: Doesn't handle pwd = /C: very well

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Wed, 05 Nov 2014 14:45:36 -0500
> Cc: 18891@debbugs.gnu.org
> 
> 
> PS this makes me think, what happens if the local file name happens to
> match a remote host that does exist...

I think the file should match a remote host prefixed with a protocol
supported by Tramp, not just the host name, for this issue to pop up.

> If as you say the design prefers remote hosts over local ones, that
> seems like a bad design to me.

I think the idea is that such files are very rare, and using the /:
prefix to quote them is the fire escape.

bug#18891: Doesn't handle pwd = /C: very well

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> PS this makes me think, what happens if the local file name happens to
>> match a remote host that does exist...
>
> I think the file should match a remote host prefixed with a protocol
> supported by Tramp, not just the host name, for this issue to pop up.

Tramp supports both "/method:host:" and just "/host:".

> I think the idea is that such files are very rare, and using the /:
> prefix to quote them is the fire escape.

Yes. But somehow I have the impression, that it doesn't work fully as
expected in Glenn's scenario. Will check.

Best regards, Michael.

bug#18891: Doesn't handle pwd = /C: very well

[Michael Albinus]

Glenn Morris <rgm@gnu.org> writes:

> PS this makes me think, what happens if the local file name happens to
> match a remote host that does exist...
>
> If as you say the design prefers remote hosts over local ones, that
> seems like a bad design to me.

Don't blame me, the design seems to be older than my liaison with Emacs
(ange-ftp.el is copyrighted since 1989; I've started with Emacs in
autumn 1990, IIRC).

You have the same problem with other file name handlers. If you work on
a file foo.gpg, epa-file-handler will be invoked just because of this
name. It doesn't matter, whether taht file is encrypted with gpg, or not.

Best regards, Michael.

bug#18891: Doesn't handle pwd = /C: very well

[Stefan Monnier]

> Don't blame me, the design seems to be older than my liaison with Emacs
> (ange-ftp.el is copyrighted since 1989; I've started with Emacs in
> autumn 1990, IIRC).

I guess Tramp could check if there's matching local dir and pass the
request through untouched if there is.


        Stefan

bug#18891: Doesn't handle pwd = /C: very well

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 05 Nov 2014 17:44:44 -0500
> Cc: 18891@debbugs.gnu.org
> 
> > Don't blame me, the design seems to be older than my liaison with Emacs
> > (ange-ftp.el is copyrighted since 1989; I've started with Emacs in
> > autumn 1990, IIRC).
> 
> I guess Tramp could check if there's matching local dir and pass the
> request through untouched if there is.

If Tramp did that, how would the user tell Tramp that it should access
the remote host, even though there is a matching local file?  (The
converse situation can be handled with /: quoting.)

bug#18891: Doesn't handle pwd = /C: very well

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Don't blame me, the design seems to be older than my liaison with Emacs
>> > (ange-ftp.el is copyrighted since 1989; I've started with Emacs in
>> > autumn 1990, IIRC).
>> 
>> I guess Tramp could check if there's matching local dir and pass the
>> request through untouched if there is.
>
> If Tramp did that, how would the user tell Tramp that it should access
> the remote host, even though there is a matching local file?  (The
> converse situation can be handled with /: quoting.)

Indeed. And there are even cases where checking a local dir wouldn't work:

(make-directory "/C:/foo/bar/baz" t)

After all, I believe the use case (local file name, which looks like a
remote one) isn't relevant enough to add ugly hacks.

Best regards, Michael.

bug#18891: Doesn't handle pwd = /C: very well

[Stefan Monnier]

>>> I guess Tramp could check if there's matching local dir and pass the
>>> request through untouched if there is.
>> If Tramp did that, how would the user tell Tramp that it should access
>> the remote host, even though there is a matching local file?  (The
>> converse situation can be handled with /: quoting.)

It could use an alternative syntax.  E.g. /ssh:C:. or /ssh:c:~ or
/ssh:c.mydomain.org: , you name it.

It seems like a sufficiently oddball case (after all, the current
assumption is that such conflicts never happen).

> Indeed. And there are even cases where checking a local dir wouldn't work:
> (make-directory "/C:/foo/bar/baz" t)

I don't see what's different, unless you were thinking of checking the
existence of "/C:/foo/bar/baz" whereas I'd only want to check the
existence of the "root", i.e. "/C:".

> After all, I believe the use case (local file name, which looks like a
> remote one) isn't relevant enough to add ugly hacks.

Agreed.  This said, I'm in favor of deprecating the "/<host>:" syntax in
favor of "/<method>:<host>:", which should make the possibility of such
conflicts even more remote (pun intended).


        Stefan

bug#18891: Doesn't handle pwd = /C: very well

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> After all, I believe the use case (local file name, which looks like a
>> remote one) isn't relevant enough to add ugly hacks.
>
> Agreed.  This said, I'm in favor of deprecating the "/<host>:" syntax in
> favor of "/<method>:<host>:", which should make the possibility of such
> conflicts even more remote (pun intended).

From implementation point of view, I'm with you. It would make parsing a
file name easier.

I suspect using the "/<host>:" syntax was motivated by a smooth
migration from ange-ftp to Tramp. One could tell people, that they
should set tramp-default-method to "ftp", and they wouldn't need to
change anything.

That's more than a decade ago. Don't know, whether Emacs users are ready
to change to "/<method>:<host>:". And a default method like "/:<host>:"
is not applicable, because "/:" is used for something different.

>         Stefan

Best regards, Michael.

bug#18891: Doesn't handle pwd = /C: very well

[Stefan Monnier]

> That's more than a decade ago.  Don't know, whether Emacs users are ready
> to change to "/<method>:<host>:".

I'm pretty sure it wouldn't be a big deal, tho we'd still have to accept
the old syntax for a while.

FWIW, I've been using systematically /<method>:<host>: for many years
now, and not to avoid conflicts but because I found it easier not to
have to worry about which method I'd get with /<host>:.


        Stefan

bug#18891: Doesn't handle pwd = /C: very well

[Andreas Schwab]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> That's more than a decade ago.  Don't know, whether Emacs users are ready
>> to change to "/<method>:<host>:".
>
> I'm pretty sure it wouldn't be a big deal, tho we'd still have to accept
> the old syntax for a while.

I would be annoyed if I have to remember what is the name of the default
method (which can differ depending on the host).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#18891: Doesn't handle pwd = /C: very well

[Stefan Monnier]

>>> That's more than a decade ago.  Don't know, whether Emacs users are ready
>>> to change to "/<method>:<host>:".
>> I'm pretty sure it wouldn't be a big deal, tho we'd still have to accept
>> the old syntax for a while.
> I would be annoyed if I have to remember what is the name of the default
> method (which can differ depending on the host).

Do you configure those methods explicitly, or do Tramp's defaults just
work for you?


        Stefan

bug#18891: Doesn't handle pwd = /C: very well

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> That's more than a decade ago.  Don't know, whether Emacs users are ready
>>>> to change to "/<method>:<host>:".
>>> I'm pretty sure it wouldn't be a big deal, tho we'd still have to accept
>>> the old syntax for a while.
>> I would be annoyed if I have to remember what is the name of the default
>> method (which can differ depending on the host).
>
> Do you configure those methods explicitly, or do Tramp's defaults just
> work for you?

I have added an element to tramp-default-method-alist.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#18891: Doesn't handle pwd = /C: very well

[Stefan Monnier]

>> Do you configure those methods explicitly, or do Tramp's defaults just
>> work for you?
> I have added an element to tramp-default-method-alist.

So maybe we should simply change tramp-default-method-alist to default
to nil, and to say that if none of the entries match, then the file is
passed through rather than handled by Tramp.


        Stefan

bug#18891: Doesn't handle pwd = /C: very well

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> So maybe we should simply change tramp-default-method-alist to default
> to nil, and to say that if none of the entries match, then the file is
> passed through rather than handled by Tramp.

If we support only "/<method>:<host>:" syntax, there is no need anymore
for tramp-default-method and tramp-default-method-alist.

>         Stefan

Best regards, Michael.

bug#18891: Doesn't handle pwd = /C: very well

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Do you configure those methods explicitly, or do Tramp's defaults just
>>> work for you?
>> I have added an element to tramp-default-method-alist.
>
> So maybe we should simply change tramp-default-method-alist to default
> to nil, and to say that if none of the entries match, then the file is
> passed through rather than handled by Tramp.

How does that fix the annoyance?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#18891: Doesn't handle pwd = /C: very well

[Stefan Monnier]

>> So maybe we should simply change tramp-default-method-alist to default
>> to nil, and to say that if none of the entries match, then the file is
>> passed through rather than handled by Tramp.
> How does that fix the annoyance?

It removes the /<host>: from the defaults (so there's no more risk of it
colliding with a local file name), but it lets you keep using that
/<host>: syntax for those specific entries you want (and if they collide
with a local file, it's your own fault).


        Stefan

bug#18891: Doesn't handle pwd = /C: very well

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> So maybe we should simply change tramp-default-method-alist to default
>>> to nil, and to say that if none of the entries match, then the file is
>>> passed through rather than handled by Tramp.
>> How does that fix the annoyance?
>
> It removes the /<host>: from the defaults (so there's no more risk of it
> colliding with a local file name), but it lets you keep using that
> /<host>: syntax for those specific entries you want (and if they collide
> with a local file, it's your own fault).

That doesn't fix the annoyance.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#18891: Doesn't handle pwd = /C: very well

[Stefan Monnier]

> That doesn't fix the annoyance.

Then I guess I don't know which annoyance you're referring to.


        Stefan

bug#18891: Doesn't handle pwd = /C: very well

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> That doesn't fix the annoyance.
>
> Then I guess I don't know which annoyance you're referring to.

I would be annoyed if I have to remember what is the name of the default
method (which can differ depending on the host).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#18891: Doesn't handle pwd = /C: very well

[Stefan Monnier]

>>> That doesn't fix the annoyance.
>> Then I guess I don't know which annoyance you're referring to.
> I would be annoyed if I have to remember what is the name of the default
> method (which can differ depending on the host).

But you wouldn't have to remember: you'd set it once and for all in
tramp-default-method-alist (you could even copy that from the setting
in 24.4 if that setting suited you) and then you would keep using
/<host>: as before.


        Stefan

bug#18891: Doesn't handle pwd = /C: very well

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> That doesn't fix the annoyance.
>>> Then I guess I don't know which annoyance you're referring to.
>> I would be annoyed if I have to remember what is the name of the default
>> method (which can differ depending on the host).
>
> But you wouldn't have to remember: you'd set it once and for all in
> tramp-default-method-alist (you could even copy that from the setting
> in 24.4 if that setting suited you) and then you would keep using
> /<host>: as before.

That works only for those that are matched by
tramp-default-method-alist.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#18891: Doesn't handle pwd = /C: very well

[Stefan Monnier]

>>>>> That doesn't fix the annoyance.
>>>> Then I guess I don't know which annoyance you're referring to.
>>> I would be annoyed if I have to remember what is the name of the default
>>> method (which can differ depending on the host).
>> 
>> But you wouldn't have to remember: you'd set it once and for all in
>> tramp-default-method-alist (you could even copy that from the setting
>> in 24.4 if that setting suited you) and then you would keep using
>> /<host>: as before.
> That works only for those that are matched by
> tramp-default-method-alist.

If you copy the 24.4 setting, then all hosts will match something.


        Stefan

bug#18891: Doesn't handle pwd = /C: very well

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>>>> That doesn't fix the annoyance.
>>>>> Then I guess I don't know which annoyance you're referring to.
>>>> I would be annoyed if I have to remember what is the name of the default
>>>> method (which can differ depending on the host).
>>> 
>>> But you wouldn't have to remember: you'd set it once and for all in
>>> tramp-default-method-alist (you could even copy that from the setting
>>> in 24.4 if that setting suited you) and then you would keep using
>>> /<host>: as before.
>> That works only for those that are matched by
>> tramp-default-method-alist.
>
> If you copy the 24.4 setting, then all hosts will match something.

No.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#18891: Doesn't handle pwd = /C: very well

[Stefan Monnier]

> No.

If you can't argument better than that, I'm afraid your opinion
won't matter.


        Stefan

bug#18891: Doesn't handle pwd = /C: very well

[Andreas Schwab]

If you can't be bothered to actually check your claims your opinion is
worth nothing.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#18891: Doesn't handle pwd = /C: very well

[Stefan Monnier]

> If you can't be bothered to actually check your claims your opinion is
> worth nothing.

Ah, thanks, now it's all much more clear,


        Stefan

bug#18891: Doesn't handle pwd = /C: very well

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> So maybe we should simply change tramp-default-method-alist to default
>>> to nil, and to say that if none of the entries match, then the file is
>>> passed through rather than handled by Tramp.
>> How does that fix the annoyance?
>
> It removes the /<host>: from the defaults (so there's no more risk of it
> colliding with a local file name), but it lets you keep using that
> /<host>: syntax for those specific entries you want (and if they collide
> with a local file, it's your own fault).

But there is also tramp-default-method, which is applied when there is
no match in tramp-default-method-alist. You would annoy all people who
haven't configured tramp-default-method-alist, and who are happy to
apply /<host>: today.

>         Stefan

Best regards, Michael.

bug#18891: Doesn't handle pwd = /C: very well

[Stefan Monnier]

> But there is also tramp-default-method, which is applied when there is
> no match in tramp-default-method-alist. You would annoy all people who
> haven't configured tramp-default-method-alist, and who are happy to
> apply /<host>: today.

Of course, that's the core of my suggestion to deprecate the
/<host>: syntax.


        Stefan

bug#18891: Doesn't handle pwd = /C: very well

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> But there is also tramp-default-method, which is applied when there is
>> no match in tramp-default-method-alist. You would annoy all people who
>> haven't configured tramp-default-method-alist, and who are happy to
>> apply /<host>: today.
>
> Of course, that's the core of my suggestion to deprecate the
> /<host>: syntax.

And that's what annoys Andreas.

>         Stefan

Best regards, Michael.

bug#18891: Doesn't handle pwd = /C: very well

[Stefan Monnier]

>>> But there is also tramp-default-method, which is applied when there is
>>> no match in tramp-default-method-alist. You would annoy all people who
>>> haven't configured tramp-default-method-alist, and who are happy to
>>> apply /<host>: today.
>> Of course, that's the core of my suggestion to deprecate the
>> /<host>: syntax.
> And that's what annoys Andreas.

So he'll have to add an entry to tramp-default-method-alist.
Doesn't sound that terrible.


        Stefan

bug#18891: Doesn't handle pwd = /C: very well

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Of course, that's the core of my suggestion to deprecate the
>>> /<host>: syntax.
>> And that's what annoys Andreas.
>
> So he'll have to add an entry to tramp-default-method-alist.
> Doesn't sound that terrible.

Looks like we are miscommunicating :-(

When the /<host>: syntax is deprecated, we must use /<method>:<host>:
There's no tramp-default-method-alist anymore.

When you still allow the /<host>: syntax, we have both
tramp-default-method-alist and tramp-default-method. The latter one is
used when there is no matching entry in tramp-default-method-alist.
Your proposal means to deprecate tramp-default-method, and to use the
/<method>:<host>: syntax for all hosts which are not matched in
tramp-default-method-alist. I don't see why it is better than the
current behaviour.

>         Stefan

Best regards, Michael.

bug#18891: Doesn't handle pwd = /C: very well

[Stefan Monnier]

> tramp-default-method-alist. I don't see why it is better than the
> current behaviour.

It's better because out of the box /<host>: won't work any more (so it
can't collide with a local dir), but if people still like it, they can
get the old behavior by customizing tramp-default-method-alist.


        Stefan

bug#18891: Doesn't handle pwd = /C: very well

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> tramp-default-method-alist. I don't see why it is better than the
>> current behaviour.
>
> It's better because out of the box /<host>: won't work any more (so it
> can't collide with a local dir), but if people still like it, they can
> get the old behavior by customizing tramp-default-method-alist.

When you proposed to deprecate the /<host>: syntax I said I'm with you
from the implementation point of view. Now your proposal still includes
this syntax, only discouraging people using it. So the promise of a
simpler implementation is not true anymore.

What's left is that we will annoy people, because tramp-default-method
won't exist anymore. They will learn soon, that (add-to-list
'tramp-default-method-alist '(nil nil "scp") t) will restore the
previous behaviour. We won't gain nothing.

And everything just for the rare-or-even-not-existing case that a user
has a local directory "/C:/" or similar. How often does it happen? I
haven't seen such reports for years (maybe never, but I distrust my
memory). Even this report is not based on an evidence in real life, but
on a 13 years old message about a problem with ange-ftp.

I don't believe this is sufficient for annoying Emacs users.

And users with such a special local directory could use "/:/C:/"
instead. Emacs supports this case already, and I've fixed some errors in
the run of this report. call-process with such a default-directory does
not work yet, but this is an error which could be fixed. It doesn't
qualify to change the Tramp design.

>         Stefan

Best regards, Michael.

bug#18891: Doesn't handle pwd = /C: very well

[Stefan Monnier]

> When you proposed to deprecate the /<host>: syntax I said I'm with you
> from the implementation point of view.  Now your proposal still includes
> this syntax, only discouraging people using it.  So the promise of a
> simpler implementation is not true anymore.

So what would you propose instead for "deprecate the /<host>: syntax"?


        Stefan

bug#18891: Doesn't handle pwd = /C: very well

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> When you proposed to deprecate the /<host>: syntax I said I'm with you
>> from the implementation point of view.  Now your proposal still includes
>> this syntax, only discouraging people using it.  So the promise of a
>> simpler implementation is not true anymore.
>
> So what would you propose instead for "deprecate the /<host>: syntax"?

In order to simplify Tramp implementation, I would propose to obsolete
the /<host>: syntax completely. Since it doesn't seem to be acceptable
by the users, I'm in favor of doing nothing. Keep it as it is.

>         Stefan

Best regards, Michael.

bug#18891: Doesn't handle pwd = /C: very well

[Stefan Monnier]

> In order to simplify Tramp implementation, I would propose to obsolete
> the /<host>: syntax completely.  Since it doesn't seem to be acceptable
> by the users, I'm in favor of doing nothing.  Keep it as it is.

OK, then.  The only other option would be to split the /<host>: handling
to a separate file-name handler which redirects those requests to
/<method>:<host>:.

So this handler can be completely independent from Tramp (and could even
work for "arbitrary" filenames rather than only /<host>:, kind of like
a mount table).

But there's no urgent need to change the status quo.


        Stefan

bug#18891: Doesn't handle pwd = /C: very well

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> But there's no urgent need to change the status quo.

Thanks.

Glenn, do you think we need more work for this report? At least
call-process is not cooperating with a default-directory "/:/C:/".
OTOH, I've spent already some hours to hunt this problem, w/o success.

>         Stefan

Best regards, Michael.

bug#18891: Doesn't handle pwd = /C: very well

[Glenn Morris]

Michael Albinus wrote:

> Glenn, do you think we need more work for this report?

No. Thanks.

bug#18891: Doesn't handle pwd = /C: very well

[Michael Albinus]

Version: 24.5

Glenn Morris <rgm@gnu.org> writes:

> Michael Albinus wrote:
>
>> Glenn, do you think we need more work for this report?
>
> No. Thanks.

Closed.

Best regards, Michael.

bug#18891: Doesn't handle pwd = /C: very well

[Michael Albinus]

Glenn Morris <rgm@gnu.org> writes:

> Well, Emacs starts now.
> It still prints
>     
>     Tramp: Opening connection for C using scp...
>     Opening connection for C using scp... \
>     Tramp: Sending command `exec ssh    -e none C'
>     Tramp: Waiting for prompts from remote shell...
>     Waiting for prompts from remote shell... \
>     Tramp: Waiting for prompts from remote shell...failed
>     Tramp: Opening connection for C using scp...failed

This is expected. But I've suppressed the 30 sec pause now, do you see?

> in the terminal, and C-x C-f shows the prompt as the weird-looking:
>
>     Find file: /:/C:/
>
> but if that is how it has to be, so be it.

*This* shall work. Prefixing absolute file names with "/:" shall suppress
all file name handlers, see (info "(emacs) Quoted File Names")

> Trying to visit a new file fails though:
>
>    C-x C-f bar RET
>
> since it again tries to do something via Tramp and fails.

Unfortune, yes. But how often does it happen, that your default
directory has such a value like "/C:/" ?

Anyway, I will check how I could convince Tramp that "/:/C:/bar"
shouldn't be touched.

Best regards, Michael.

bug#18891: Doesn't handle pwd = /C: very well

[Glenn Morris]

Michael Albinus wrote:

> This is expected. But I've suppressed the 30 sec pause now, do you see?

Yes, no pause.

> Unfortune, yes. But how often does it happen, that your default
> directory has such a value like "/C:/" ?

Never! :)

I did say this was severity: minor... :)

bug#18891: Doesn't handle pwd = /C: very well

[Michael Albinus]

Glenn Morris <rgm@gnu.org> writes:

> in the terminal, and C-x C-f shows the prompt as the weird-looking:
>
>     Find file: /:/C:/
>
> but if that is how it has to be, so be it.

This still doesn't work. dired applies call-process internally, and
there seem to be several side effects which I couldn't trap.

> Trying to visit a new file fails though:
>
>    C-x C-f bar RET
>
> since it again tries to do something via Tramp and fails.

This shall work now, both cases bar being an existing file, and bar not
existing. I've committed respective patches to the emacs-24 branch.

Although not *everything* is working correctly (call-process), I would
propose to close the bug. It's not important enough.

Best regards, Michael.

bug#18891: Doesn't handle pwd = /C: very well

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  Eli Zaretskii <eliz@gnu.org>,  18891@debbugs.gnu.org
> Date: Fri, 07 Nov 2014 15:52:37 +0100
> 
> >    C-x C-f bar RET
> >
> > since it again tries to do something via Tramp and fails.
> 
> This shall work now, both cases bar being an existing file, and bar not
> existing. I've committed respective patches to the emacs-24 branch.

Your change calls Ffile_accessible_directory_p, Fstring_match, and
Fsubstring with a unibyte (encoded) string as their argument.  I think
we should avoid that, as, e.g., Fstring_match might yield a false
positive under some encodings.

bug#18891: Doesn't handle pwd = /C: very well

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> Your change calls Ffile_accessible_directory_p, Fstring_match, and
> Fsubstring with a unibyte (encoded) string as their argument.  I think
> we should avoid that, as, e.g., Fstring_match might yield a false
> positive under some encodings.

Shall I change it like this?

--8<---------------cut here---------------start------------->8---
*** /usr/local/src/emacs-24/src/callproc.c.~117680~	2014-11-07 17:54:37.318055813 +0100
--- /usr/local/src/emacs-24/src/callproc.c	2014-11-07 17:54:03.865559094 +0100
***************
*** 150,157 ****
  
    dir = expand_and_dir_to_file (dir, Qnil);
  
-   if (STRING_MULTIBYTE (dir))
-     dir = ENCODE_FILE (dir);
    if (NILP (Ffile_accessible_directory_p (dir)))
      report_file_error ("Setting current directory",
  		       BVAR (current_buffer, directory));
--- 150,155 ----
***************
*** 160,165 ****
--- 158,166 ----
    if (Fstring_match (build_string ("^/:"), dir, Qnil))
      dir = Fsubstring (dir, make_number (2), Qnil);
  
+   if (STRING_MULTIBYTE (dir))
+     dir = ENCODE_FILE (dir);
+ 
    RETURN_UNGCPRO (dir);
  }
  
--8<---------------cut here---------------end--------------->8---

Best regards, Michael.

bug#18891: Doesn't handle pwd = /C: very well

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: rgm@gnu.org,  monnier@iro.umontreal.ca,  18891@debbugs.gnu.org
> Date: Fri, 07 Nov 2014 17:58:30 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Your change calls Ffile_accessible_directory_p, Fstring_match, and
> > Fsubstring with a unibyte (encoded) string as their argument.  I think
> > we should avoid that, as, e.g., Fstring_match might yield a false
> > positive under some encodings.
> 
> Shall I change it like this?

Yes, I think this is much better.  Thanks.

bug#18891: Doesn't handle pwd = /C: very well

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> Shall I change it like this?
>
> Yes, I think this is much better.  Thanks.

Done.

Best regards, Michael.