Change in 28.1 in opening a file from grep results on Windows

Change in 28.1 in opening a file from grep results on Windows

[Pascal Quesseveur]

Emacs 28.1 on Windows.

c:\Users\Public\app is a symbolic link to either a remote directory on
a SMB server or a local disk

I can open file c:\Users\Public\app\file1.c, and launch a command from
that file, eg an ant build

I execute grep from c:\Users\Public\app\file1.c. When I open a file in
results buffer (eg file2.c), the file is opened with its true name,
\\smbserver\app\file2.c, and then I can not execute same command as
before on file1.c because cmd.exe is not allowed from a remote
directory.

To verify file existence in compilation-find-file, emacs calls
file-truename instead of expand-file-name (version 27.1). In my case
the later is better, but I am not aware of all the possible cases.


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: Change in 28.1 in opening a file from grep results on Windows

[Eli Zaretskii]

> From: Pascal Quesseveur <pquessev@gmail.com>
> Date: Tue, 12 Jul 2022 17:36:50 +0200
> 
> Emacs 28.1 on Windows.
> 
> c:\Users\Public\app is a symbolic link to either a remote directory on
> a SMB server or a local disk
> 
> I can open file c:\Users\Public\app\file1.c, and launch a command from
> that file, eg an ant build
> 
> I execute grep from c:\Users\Public\app\file1.c. When I open a file in
> results buffer (eg file2.c), the file is opened with its true name,
> \\smbserver\app\file2.c, and then I can not execute same command as
> before on file1.c because cmd.exe is not allowed from a remote
> directory.

This is not entirely clear: what exactly happens when you do that?  If
you see error messages, please show the exact text of those messages.

As a workaround: can you map the directory on the SMB server to a
drive letter, and then change the symbolic link to use that drive
letter instead of the literal \\smbserver\foo\ remote directory?  If
you do that, does it work around the problem?

Re: Change in 28.1 in opening a file from grep results on Windows

[Eli Zaretskii]

> From: Pascal Quesseveur <pquessev@gmail.com>
> Date: Tue, 12 Jul 2022 17:36:50 +0200
> 
> To verify file existence in compilation-find-file, emacs calls
> file-truename instead of expand-file-name (version 27.1). In my case
> the later is better, but I am not aware of all the possible cases.

The reason for the change is described in bug#8035, which is even
nastier than this one.  So we cannot possibly go back to the old code
there.

It is IME unusual to use literal UNCs in serious development on
MS-Windows, precisely because cmd.exe doesn't support that well, and
various commands will fail depending on how you invoke them and what
is the working directory when you do.  Wherever I saw networked drive
used it was always via mapping them to a drive letter, and for a good
reason.

So I still think this is the right solution, not even a workaround,
because the same problems will happen outside Emacs if you use cmd.exe
as your shell.

Re: Change in 28.1 in opening a file from grep results on Windows

[Pascal Quesseveur]

>"EZ" == Eli Zaretskii <eliz@gnu.org> writes:

  EZ> This is not entirely clear: what exactly happens when you do
  EZ> that?  If you see error messages, please show the exact text of
  EZ> those messages.

It is not an Emacs error. It is an error coming from the launched
process.

\\smbserver\foo
CMD.exe été démarré avec le chemin d'accès comme répertoire en cours.
Les chemins d'accès UNC ne sont pas pris en charge....

  EZ> As a workaround: can you map the directory on the SMB server to a
  EZ> drive letter, and then change the symbolic link to use that drive
  EZ> letter instead of the literal \\smbserver\foo\ remote directory?  If
  EZ> you do that, does it work around the problem?

Yes it does. But it is not what I want. And it used to work until last
Emacs version. So my question is: was the change made for some
legitimate reason or is it just cosmetic?


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: Change in 28.1 in opening a file from grep results on Windows

[Eli Zaretskii]

> From: Pascal Quesseveur <pquessev@gmail.com>
> Date: Tue, 12 Jul 2022 18:31:25 +0200
> 
> >"EZ" == Eli Zaretskii <eliz@gnu.org> writes:
> 
>   EZ> This is not entirely clear: what exactly happens when you do
>   EZ> that?  If you see error messages, please show the exact text of
>   EZ> those messages.
> 
> It is not an Emacs error. It is an error coming from the launched
> process.
> 
> \\smbserver\foo
> CMD.exe été démarré avec le chemin d'accès comme répertoire en cours.
> Les chemins d'accès UNC ne sont pas pris en charge....

I know that the error comes from cmd.exe.  But I wanted to see what
kind of commands trigger it.

Is the command that you have shown something you actually type from
Emacs?  If so, for what purpose?

Your original description was:

> I execute grep from c:\Users\Public\app\file1.c. When I open a file in
> results buffer (eg file2.c), the file is opened with its true name,
> \\smbserver\app\file2.c, and then I can not execute same command as
> before on file1.c because cmd.exe is not allowed from a remote
> directory.

So what is that "same command as before on file1.c"?  And if you
invoke it, how does the error manifest itself?  E.g., does Emacs
signal an error and/or enter the Lisp debugger and show Lisp
backtrace?

>   EZ> As a workaround: can you map the directory on the SMB server to a
>   EZ> drive letter, and then change the symbolic link to use that drive
>   EZ> letter instead of the literal \\smbserver\foo\ remote directory?  If
>   EZ> you do that, does it work around the problem?
> 
> Yes it does. But it is not what I want. And it used to work until last
> Emacs version. So my question is: was the change made for some
> legitimate reason or is it just cosmetic?

I answered that question in my previous message: it wasn't a cosmetic
change.

Re: Change in 28.1 in opening a file from grep results on Windows

[Pascal Quesseveur]

>"EZ" == Eli Zaretskii <eliz@gnu.org> writes:

  EZ> The reason for the change is described in bug#8035, which is even
  EZ> nastier than this one.  So we cannot possibly go back to the old code
  EZ> there.

Ok.

  EZ> It is IME unusual to use literal UNCs in serious development on
  EZ> MS-Windows, precisely because cmd.exe doesn't support that well, and
  EZ> various commands will fail depending on how you invoke them and what
  EZ> is the working directory when you do.  Wherever I saw networked drive
  EZ> used it was always via mapping them to a drive letter, and for a good
  EZ> reason.

  EZ> So I still think this is the right solution, not even a workaround,
  EZ> because the same problems will happen outside Emacs if you use cmd.exe
  EZ> as your shell.

When I use cmd, I follow the symbolic link and I don't get problems. I
use some IDEs which work fine also, the only problem is that regularly
they save the absolute path in the config files, but I can manage
that.

It's still not very consistent in Emacs. If I open a dired buffer on
the linked directory, and open a file from the dired buffer, its path
is that of the linked directory. If I open a file from the compilation
buffer its path is that of the target directory.


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: Change in 28.1 in opening a file from grep results on Windows

[Pascal Quesseveur]

>"EZ" == Eli Zaretskii <eliz@gnu.org> writes:

  EZ> I know that the error comes from cmd.exe.  But I wanted to see what
  EZ> kind of commands trigger it.

  EZ> Is the command that you have shown something you actually type from
  EZ> Emacs?  If so, for what purpose?

It is a build command using ant. When I launch the build from a file
whose path is the symlink it works, when I launch the build from a
file whose path is the real one it doesn't work.

  EZ> So what is that "same command as before on file1.c"?  And if you
  EZ> invoke it, how does the error manifest itself?  E.g., does Emacs
  EZ> signal an error and/or enter the Lisp debugger and show Lisp
  EZ> backtrace?

As I said, there is no Emacs error. It's just the compilation that
can't be run.


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: Change in 28.1 in opening a file from grep results on Windows

[Eli Zaretskii]

> From: Pascal Quesseveur <pquessev@gmail.com>
> Date: Tue, 12 Jul 2022 18:56:59 +0200
> 
>   EZ> It is IME unusual to use literal UNCs in serious development on
>   EZ> MS-Windows, precisely because cmd.exe doesn't support that well, and
>   EZ> various commands will fail depending on how you invoke them and what
>   EZ> is the working directory when you do.  Wherever I saw networked drive
>   EZ> used it was always via mapping them to a drive letter, and for a good
>   EZ> reason.
> 
>   EZ> So I still think this is the right solution, not even a workaround,
>   EZ> because the same problems will happen outside Emacs if you use cmd.exe
>   EZ> as your shell.
> 
> When I use cmd, I follow the symbolic link and I don't get problems. I
> use some IDEs which work fine also, the only problem is that regularly
> they save the absolute path in the config files, but I can manage
> that.
> 
> It's still not very consistent in Emacs. If I open a dired buffer on
> the linked directory, and open a file from the dired buffer, its path
> is that of the linked directory. If I open a file from the compilation
> buffer its path is that of the target directory.

Which is why I asked what commands you tried that gave you trouble.

Emacs assumes that the shell can access any valid file name.  Since in
this case the assumption is incorrect, things do break, and that is
not a surprise.  We could perhaps make fewer commands fail if we
understand the issue better, but there's no chance we can solve it
completely.  Which is why I think using a drive letter is a better
solution in the long run.

Re: Change in 28.1 in opening a file from grep results on Windows

[Eli Zaretskii]

> From: Pascal Quesseveur <pquessev@gmail.com>
> Date: Tue, 12 Jul 2022 19:04:53 +0200
> 
>   EZ> Is the command that you have shown something you actually type from
>   EZ> Emacs?  If so, for what purpose?
> 
> It is a build command using ant. When I launch the build from a file
> whose path is the symlink it works, when I launch the build from a
> file whose path is the real one it doesn't work.

Then I guess "M-x cd" before invoking the build command should fix the
problem?

Or maybe you could write a simple find-file-hook which would set
default-directory in each buffer of the files you visit to use the
symlink name?

Re: Change in 28.1 in opening a file from grep results on Windows

[Pascal Quesseveur]

>"EZ" == Eli Zaretskii <eliz@gnu.org> writes:

  EZ> completely.  Which is why I think using a drive letter is a better
  EZ> solution in the long run.

It's not what I want. I switched from drive letters to symlinks some
years ago, and I am happy with it. I use links to hide the
implementation of directories: one or more servers, or local disks.


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: Change in 28.1 in opening a file from grep results on Windows

[Pascal Quesseveur]

>"EZ" == Eli Zaretskii <eliz@gnu.org> writes:

  EZ> Then I guess "M-x cd" before invoking the build command should fix the
  EZ> problem?

Yes.

  EZ> Or maybe you could write a simple find-file-hook which would set
  EZ> default-directory in each buffer of the files you visit to use the
  EZ> symlink name?

Yes, I know that. My question was about the change. I will have to
adapt to it.

Thanks


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: Change in 28.1 in opening a file from grep results on Windows

[Eli Zaretskii]

> From: Pascal Quesseveur <pquessev@gmail.com>
> Date: Tue, 12 Jul 2022 19:20:28 +0200
> 
> >"EZ" == Eli Zaretskii <eliz@gnu.org> writes:
> 
>   EZ> completely.  Which is why I think using a drive letter is a better
>   EZ> solution in the long run.
> 
> It's not what I want. I switched from drive letters to symlinks some
> years ago, and I am happy with it. I use links to hide the
> implementation of directories: one or more servers, or local disks.

You could map \\smbserver\foo to drive Y:, say, and then symlink to
Y:\ instead of the server.  Doesn't that work and allow you to hide
the implementation just the same?

An alternative is to make a local change in compilation-find-file to
not use file-truename (assuming that the problem in bug#8035 can never
happen to you).

Anyway, you are fighting Windows here, so I can only wish you good
luck in that fight.  (And maybe some day they will remove this
limitation from cmd.exe.  More improbable miracles have happened...)

Re: Change in 28.1 in opening a file from grep results on Windows

[Pascal Quesseveur]

>"EZ" == Eli Zaretskii <eliz@gnu.org> writes:

  EZ> An alternative is to make a local change in compilation-find-file to
  EZ> not use file-truename (assuming that the problem in bug#8035 can never
  EZ> happen to you).

I suppose the bug never happen to me becaus I didn't got it until
now. But the simplest thing is a hook in find-file-hook, to set
default-directory. I suppose I can set buffer-file-name too.

  EZ> Anyway, you are fighting Windows here, so I can only wish you
  EZ> good luck in that fight.  (And maybe some day they will remove
  EZ> this limitation from cmd.exe.  More improbable miracles have
  EZ> happened...)

I don't have that many problems, and I'm pretty happy with how it
works.


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: Change in 28.1 in opening a file from grep results on Windows

[Stefan Monnier via Users list for the GNU Emacs text editor]

> It's still not very consistent in Emacs. If I open a dired buffer on
> the linked directory, and open a file from the dired buffer, its path
> is that of the linked directory. If I open a file from the compilation
> buffer its path is that of the target directory.

Can you try setting up `directory-abbrev-alist`?

AFAIK it was introduced for similar purposes (e.g. for people using the
old `amd` automounter which turned /net/<host> into a symlink to
/tmp_mnt/<host>, but if you stopped using the symlink `amd` would then
unmount /tmp_mnt/<host> after a timeout and your direct access to
/tmp_mnt/<host> would then fail).


        Stefan

Re: Change in 28.1 in opening a file from grep results on Windows

[Eli Zaretskii]

> Date: Tue, 12 Jul 2022 16:07:23 -0400
> From:  Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> > It's still not very consistent in Emacs. If I open a dired buffer on
> > the linked directory, and open a file from the dired buffer, its path
> > is that of the linked directory. If I open a file from the compilation
> > buffer its path is that of the target directory.
> 
> Can you try setting up `directory-abbrev-alist`?
> 
> AFAIK it was introduced for similar purposes (e.g. for people using the
> old `amd` automounter which turned /net/<host> into a symlink to
> /tmp_mnt/<host>, but if you stopped using the symlink `amd` would then
> unmount /tmp_mnt/<host> after a timeout and your direct access to
> /tmp_mnt/<host> would then fail).

That variable is supposed to be set up for each symlinked directory?
I think that is only reasonable to expect if a symlink never changes,
which is not what happens in this case, AFAIU.

Re: Change in 28.1 in opening a file from grep results on Windows

[Stefan Monnier via Users list for the GNU Emacs text editor]

>> Can you try setting up `directory-abbrev-alist`?
>> 
>> AFAIK it was introduced for similar purposes (e.g. for people using the
>> old `amd` automounter which turned /net/<host> into a symlink to
>> /tmp_mnt/<host>, but if you stopped using the symlink `amd` would then
>> unmount /tmp_mnt/<host> after a timeout and your direct access to
>> /tmp_mnt/<host> would then fail).
>
> That variable is supposed to be set up for each symlinked directory?
> I think that is only reasonable to expect if a symlink never changes,
> which is not what happens in this case, AFAIU.

It's a regexp match & replace, so to some extend a single entry can
handle various symlinks, but yes, it's static, and it requires manual
set up.

IIUC in his case, the symlink is still static: it can point either to
a remote directory or to a local disk, but that depends only on the
machine on which it's run, right?

We could write a function which takes a list of "possible symlinks" and
builds a set of entries for `directory-abbrev-alist` to try and convince
Emacs to use the "clean names using symlinks" in preference to the
target of those symlinks.
[ I seem to remember that I had such a function, many years ago, but
  somehow I can't find it any more, even though I'm pretty lazy when it
  comes to erasing unused code from my .emacs.  Maybe I dreamt it.  ]


        Stefan

Re: Change in 28.1 in opening a file from grep results on Windows

[Pascal Quesseveur]

>"SM" == Stefan Monnier <help-gnu-emacs@gnu.org> writes:

  SM> IIUC in his case, the symlink is still static: it can point
  SM> either to a remote directory or to a local disk, but that
  SM> depends only on the machine on which it's run, right?

Yes it is something like that. I just checked and it is working
fine. I can set a regexp matching local drives and smb servers, the
match is always replaced by the same dir.

  SM> We could write a function which takes a list of "possible
  SM> symlinks" and builds a set of entries for
  SM> `directory-abbrev-alist` to try and convince Emacs to use the
  SM> "clean names using symlinks" in preference to the target of
  SM> those symlinks.

I don't even need something that complicated.

Thanks a lot.


-- 
Pascal Quesseveur
pquessev@gmail.com