Windows bash shell c:/path style auto-completion

[mitchcapper]

While msys normally uses paths like:
/c/temp/apples
it implicitly accepts paths like:
c:/temp/apples

the benefit of the second path is it is universal. Works in msys shells and with native windows commands. As far as I know it is the easiest way to write a universal path. The one downside is there is no bash autocompletion for that style path. I think it would be possible to do so with a bash completion script for args to any commands, but I am not sure how one modifies the completion for the initial command itself.

[dscho]

The one downside is there is no bash autocompletion for that style path.

The "two downside" is that it interacts really badly with path lists such as PATH that Bash expects to be colon-separated.

[sskras]

@dscho, I would like to add:

• colon chars can be successfully escaped, if we really mean processing only by the Bash itself. ^[1]
• if some list-var receives a path like c:/temp/apples by hand (interactively), this is easy to spot & do right (by quickly noticing the : being the 2nd char, near start of the string being added):
  
  c\:/temp/apples
   
• if a path like c:/temp/apples gets calculated (extracted) during runtime of a script which then writes it to some list-var, scenarios like this might need detection + fixing (escaping) in the path writer.
• now if the path reader does not understand character escaping ^[1], fixing this would require a bit different effort depending on the what is the writer. ^[2]

Because of that I think:

• Path forms like c:/temp/apples should work in an interactive scenarios.
• Escaped path forms like c\:/temp/apples should be tested against a specific list-variable.
• Forms like /c/temp/apples should be left in use for the rest of cases (primarily during the internal path translation).

^[1] Such PATHs won't work with execlp(), execvp(), and execvpe() calls. Not sure how frequent are they these days.
Bash uses only execve on its' own, which seems to ignore PATH.

^[2] Fixing reader might require patching some system libs, esp. libc. So it might would be a bit different effort than fixing your own scripts. But in the case of software like MSYS it's also doable.

[sskras]

PS. I even see a possiblity to patch the PATH parsing logic in libc so that it detects eg. C:/temp in the PATH without any escaping.

Eg: PATH=/bin:C:/temp:/opt/bin

0. Start from the 1st characters in the list;
1. Scan them sequentially;
2. Upon : check if the already scanned name in the buffer isn't a single letter;
3. If it's a single letter, replace both the letter C and the : in the buffer with the /C string:
   => /bin:/C/temp:/opt/bin
4. If it's something else (usually a longer string, eg. /bin or /C/temp), add it to the resulting array;
5. Continue scanning like in the step 1.
6. Use the built array:
   /bin
/C/temp
/opt/bin

The only contra in such case would be losing one-letter long relative directories from you PATH.
Is it this a frequent usage scenario? I highly doubt that.

[mitchcapper]

I implemented a similar PATH solution to your suggestion here, it worked quite well. Agree the potential loss of one letter root dirs, but does seem very unlikely for most users. I think worst case could be something like MSYS2_ARG_CONV_EXCL where you could exclude specific one letter paths, but I doubt this is a big problem.

[sskras]

@mitchcapper, cool! Re one letter long paths: it would be a relative pathname, and I doubt anyone is using relative pathnames in paths.

Except maybe for . when the user is annoyed by prepending name of his script with ./ when running from the current dir (IOW when a user like me wants the Windows-like behavior back).

[sskras]

Just a thought:

If the project would be directly installed into C:\, the user could use rely on /temp/apples notation regardless of the environment and without involving any changes to the MSYS2 engine.

[sskras]

PS. Actually this is quite dangerous.

I tried doing that, and MSYS2 warns that the directory would be cleaned upon uninstallation.
And the drive was wiped after I uninstalled MSYS2. So this is very dangerous at the moment.

[claramoraes2014]

Thanks for tip)

[sskras]

Not sure what tip do you refer to, but in case it was about installing MSYS2 into C:\, I added a warning under my original comment. Cheers.