ls '..\..\' do not work

[dhoegh]

Hi I found that ls '..\..\' do not work but cd '..\..\' while I have been working on this issue julialang/julia#8693. It could be nice to fix this behavior. My version is 1.9.4 that is shipped with Julialang.

[t-b]

What shell? Have you tried doubling the backslashes? If you are working with bash I would use slashes '/'.

[dhoegh]

It is when using the bash shell. Yes I know it works with ´/´, but it was more in inconsistency between cd and ls and it do also work when this is done: ls 'Documents\..\'. The reason of the use of backslashes, come from how Julia is shelling out to the bash and that was how I discovered the inconsistency.

[t-b]

If it works with '/' then stick to it please. I guess the reason for the discrepancy is that cd is a bash builtin and ls a command.

[dscho]

The reason of the use of backslashes, come from how Julia is shelling out to the bash and that was how I discovered the inconsistency.

That is a bug in Julia, then. All Unix shells use the backslashes as escape characters and forward slashes for directory separators.

Therefore I agree with @t-b that this is not a bug in Bash, let alone in Git for Windows.

[tkelman]

Yes, Julia using msysgit is indeed a bug in Julia that we hope to fix :)

ls with double-backslashes works fine in Cygwin (with a warning), MSYS2 (with no warning), and busybox-win32 (no warning). If anything this is an MSYS1 bug, due to using very old coreutils.

[t-b]

If anything this is an MSYS1 bug, due to using very old coreutils.

You can verify that by trying out https://github.com/git-for-windows/sdk which is the designated successor to msysgit.

[tkelman]

That's still MSYS1, just a slightly more recent version using mingw-get, right? Looks like that's at coreutils 5.97, rather than fileutils 4.1. Most other non-legacy environments are at coreutils 8.23 now. At least I can do touch -c nonexistent && echo ok in an up-to-date MSYS1 (can't in msysgit), but ls from coreutils 5.97 in MSYS1 doesn't understand double-backslashes either.

[dscho]

@tkelman I encourage you to use the correct names: Bash when you are referring to Bash problems (as opposed to Git problems) and Git foir Windows when referring to Git problems on Windows (as opposed to msysGit). :-)

[tkelman]

@dscho sure. Is anything mentioned in this issue so far a Bash problem though? Every problem mentioned here is due to the old version of coreutils included in "the msys part of Git for Windows," sorry that's a mouthful if "msysgit" is not the same thing. Bash is just the shell, and when git-bash is used within "Git for Windows" the coreutils executables are getting called. A Bash problem would be that both "Git for Windows" and MSYS1 include 3.1.x versions of Bash that appear to be vulnerable to shellshock, but I'm sure you know that already.

[dscho]

@tkelman you made it sound as if msysGit was the problem, when the real problem is the incorrect use of backslashes in the call to ls, and when msysGit is not involved at all, and when this was reported on the Git for Windows bugtracker. I am sorry that I pointed out those problems.

[tkelman]

@dscho sorry for using the wrong names. All I'm saying is if git for windows was using a more modern version of coreutils then ls would, in all likelihood, accept backslashes. So you can close this as wontfix if that's an unrealistic amount of effort. (nevermind, already is closed)

[tkelman]

We're also not really using bash, @dhoegh was slightly mistaken when he said

Julia is shelling out to the bash

That's not quite true. Julia does shell out to a bundled copy of portable git for its package manager (on Windows), though hopefully this will not always be the case. In order for that portable git executable to function correctly, we need to temporarily add the bin directory of the portable Git for Windows installation to our path. That brings in Git for Windows' copies of ls and other coreutils executables which have undesirably restrictive behavior due to their age.