bug#70012: shell-resync-dirs broken on windows

bug#70012: shell-resync-dirs broken on windows

[Sam Steingold]

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

Windows emacs 29.2
Msys2 bash dirs returns something like "/c/foo" for "c:/foo" and
(file-directory-p "/c/foo") returns nil even though "c:/foo" is a directory.
Thus shell-resync-dirs goes into an infinite loop.

[-- Attachment #2: Type: text/html, Size: 318 bytes --]

bug#70012: shell-resync-dirs broken on windows

[Eli Zaretskii]

tags 70012 notabug wontfix
thanks

> From: Sam Steingold <sds@gnu.org>
> Date: Tue, 26 Mar 2024 12:25:13 -0400
> 
> Windows emacs 29.2
> Msys2 bash dirs returns something like "/c/foo" for "c:/foo" and (file-directory-p "/c/foo") returns nil even
> though "c:/foo" is a directory.
> Thus shell-resync-dirs goes into an infinite loop.

Sorry, the native Windows build of Emacs is not supposed to support
MSYS- or Cygwin-specific magic in file names.  We cannot support that
without significant complications in the low-level code, and even if
that code can be made to work, users are not supposed to give up
top-level directories named /x (where 'x' is a letter).

If you want these names supported, try the Cygwin or Cygw32 build
instead (but I'm not sure even those builds support /c/foo/bar file
names).

This is not a bug, and we should not even try fixing it.  IOW, using
MSYS Bash in shell buffers is not supported in the MS-Windows build.

bug#70012: shell-resync-dirs broken on windows

[Sam Steingold]

which bash builds are supported on windows?

On Tue, 26 Mar 2024 at 12:52, Eli Zaretskii <eliz@gnu.org> wrote:
>
> tags 70012 notabug wontfix
> thanks
>
> > From: Sam Steingold <sds@gnu.org>
> > Date: Tue, 26 Mar 2024 12:25:13 -0400
> >
> > Windows emacs 29.2
> > Msys2 bash dirs returns something like "/c/foo" for "c:/foo" and (file-directory-p "/c/foo") returns nil even
> > though "c:/foo" is a directory.
> > Thus shell-resync-dirs goes into an infinite loop.
>
> Sorry, the native Windows build of Emacs is not supposed to support
> MSYS- or Cygwin-specific magic in file names.  We cannot support that
> without significant complications in the low-level code, and even if
> that code can be made to work, users are not supposed to give up
> top-level directories named /x (where 'x' is a letter).
>
> If you want these names supported, try the Cygwin or Cygw32 build
> instead (but I'm not sure even those builds support /c/foo/bar file
> names).
>
> This is not a bug, and we should not even try fixing it.  IOW, using
> MSYS Bash in shell buffers is not supported in the MS-Windows build.



-- 
Sam Steingold <http://sds.podval.org> <http://www.childpsy.net>
<http://steingoldpsychology.com>

bug#70012: shell-resync-dirs broken on windows

[Eli Zaretskii]

> From: Sam Steingold <sds@gnu.org>
> Date: Wed, 27 Mar 2024 19:37:00 -0400
> Cc: 70012@debbugs.gnu.org
> 
> which bash builds are supported on windows?

Any native build of Bash would be supported.  Except that I'm not
aware of any such port of Bash, unfortunately.

Maybe the MSYS or Cygwin Bash can be told to output Windows-format
file names with drive letters?  I know that "pwd -W", for example,
shows the current directory in Windows format, so maybe there are
other similar tricks?

bug#70012: shell-resync-dirs broken on windows

[Sam Steingold]

On Thu, Mar 28, 2024, 02:59 Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Sam Steingold <sds@gnu.org>
> > which bash builds are supported on windows?
>
> Any native build of Bash would be supported.  Except that I'm not
> aware of any such port of Bash, unfortunately.

I admire your sense of humor.

> Maybe the MSYS or Cygwin Bash can be told to output Windows-format
> file names with drive letters?  I know that "pwd -W", for example,
> shows the current directory in Windows format, so maybe there are
> other similar tricks?

Please upvote https://github.com/msys2/MSYS2-packages/issues/4472
(however, even with `dirs -W`, emacs would need to be patched)

Incidentally, why do you use `dirs` instead of `pwd` there?
you use only the last dir anyway.

finally, the following patch fixes the bug for me:

--- shell.el~ 2024-03-06 12:13:15.134281800 -0500
+++ shell.el 2024-03-28 11:50:32.920026000 -0400
@@ -711,6 +711,7 @@
    ((string-equal shell "ksh") "echo $PWD ~-")
    ;; Bypass any aliases.  TODO all shells could use this.
    ((string-equal shell "bash") "command dirs")
+   ((string-equal shell "bash.exe") "command pwd -W")
    ((string-equal shell "zsh") "dirs -l")
    (t "dirs")))
       ;; Bypass a bug in certain versions of bash.

may I push it?

bug#70012: shell-resync-dirs broken on windows

[Eli Zaretskii]

> From: Sam Steingold <sds@gnu.org>
> Date: Fri, 29 Mar 2024 08:17:26 -0400
> Cc: 70012@debbugs.gnu.org
> 
> On Thu, Mar 28, 2024, 02:59 Eli Zaretskii <eliz@gnu.org> wrote:
> > > From: Sam Steingold <sds@gnu.org>
> > > which bash builds are supported on windows?
> >
> > Any native build of Bash would be supported.  Except that I'm not
> > aware of any such port of Bash, unfortunately.
> 
> I admire your sense of humor.

<Bows>

Btw, I do have a (very old) native build of Bash on my system, but I
don't use it as it is quite buggy, and cannot reliably run complicated
shell scripts.  IOW, it isn't like no one tried to produce a native
port, they just didn't do well enough...

> > Maybe the MSYS or Cygwin Bash can be told to output Windows-format
> > file names with drive letters?  I know that "pwd -W", for example,
> > shows the current directory in Windows format, so maybe there are
> > other similar tricks?
> 
> Please upvote https://github.com/msys2/MSYS2-packages/issues/4472

Done.

> finally, the following patch fixes the bug for me:
> 
> --- shell.el~ 2024-03-06 12:13:15.134281800 -0500
> +++ shell.el 2024-03-28 11:50:32.920026000 -0400
> @@ -711,6 +711,7 @@
>     ((string-equal shell "ksh") "echo $PWD ~-")
>     ;; Bypass any aliases.  TODO all shells could use this.
>     ((string-equal shell "bash") "command dirs")
> +   ((string-equal shell "bash.exe") "command pwd -W")
>     ((string-equal shell "zsh") "dirs -l")
>     (t "dirs")))
>        ;; Bypass a bug in certain versions of bash.
> 
> may I push it?

That's not really TRT, because it assumes every bash.exe is an MSYS
program (which might not be true: there's a Cygwin Bash, for example).
And we don't need to make such assumptions:

  (w32-application-type (executable-find "bash.exe"))
   => msys

I'm okay with installing the fix after you change it to use
w32-application-type (and verifying that it works in your case, of
course: I don't have MSYS2 Bash installed).

> Incidentally, why do you use `dirs` instead of `pwd` there?
> you use only the last dir anyway.

I don't know, I'm not familiar with shell.el well enough.  Just by
looking at the code, shell-resync-dirs does need to know all the
stack, so it could refresh the value of shell-dirstack, no?

bug#70012: shell-resync-dirs broken on windows

[Sam Steingold]

On Fri, 29 Mar 2024 at 09:14, Eli Zaretskii <eliz@gnu.org> wrote:
> > finally, the following patch fixes the bug for me:
> >
> > --- shell.el~ 2024-03-06 12:13:15.134281800 -0500
> > +++ shell.el 2024-03-28 11:50:32.920026000 -0400
> > @@ -711,6 +711,7 @@
> >     ((string-equal shell "ksh") "echo $PWD ~-")
> >     ;; Bypass any aliases.  TODO all shells could use this.
> >     ((string-equal shell "bash") "command dirs")
> > +   ((string-equal shell "bash.exe") "command pwd -W")
> >     ((string-equal shell "zsh") "dirs -l")
> >     (t "dirs")))
> >        ;; Bypass a bug in certain versions of bash.
> >
> > may I push it?
>
> That's not really TRT, because it assumes every bash.exe is an MSYS
> program (which might not be true: there's a Cygwin Bash, for example).

I am pretty sure they are compatible in this way.

> And we don't need to make such assumptions:
>
>   (w32-application-type (executable-find "bash.exe"))
>    => msys
>
> I'm okay with installing the fix after you change it to use
> w32-application-type (and verifying that it works in your case, of
> course: I don't have MSYS2 Bash installed).

done.

> > Incidentally, why do you use `dirs` instead of `pwd` there?
> > you use only the last dir anyway.
>
> I don't know, I'm not familiar with shell.el well enough.  Just by
> looking at the code, shell-resync-dirs does need to know all the
> stack, so it could refresh the value of shell-dirstack, no?

nope.
`pwd` is already used for sh and ksh.
only the last line of `dirs` output is ever used.

bug#70012: shell-resync-dirs broken on windows

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> tags 70012 notabug wontfix
> thanks
>
>> From: Sam Steingold <sds@gnu.org>
>> Date: Tue, 26 Mar 2024 12:25:13 -0400
>>
>> Windows emacs 29.2
>> Msys2 bash dirs returns something like "/c/foo" for "c:/foo" and (file-directory-p "/c/foo") returns nil even
>> though "c:/foo" is a directory.
>> Thus shell-resync-dirs goes into an infinite loop.
>
> Sorry, the native Windows build of Emacs is not supposed to support
> MSYS- or Cygwin-specific magic in file names.  We cannot support that
> without significant complications in the low-level code, and even if
> that code can be made to work, users are not supposed to give up
> top-level directories named /x (where 'x' is a letter).
>
> If you want these names supported, try the Cygwin or Cygw32 build
> instead (but I'm not sure even those builds support /c/foo/bar file
> names).
>
> This is not a bug, and we should not even try fixing it.  IOW, using
> MSYS Bash in shell buffers is not supported in the MS-Windows build.

I'm therefore closing this bug report.