From: Group W <gro...@gm...> - 2007-04-26 14:28:52
|
I noticed that in a shell script the path: "C:/Documents and Settings/<user ommitted>/My Documents" is incorrectly being converted to: "C;<msys installation dir>/Documents and Settings/<user ommitted>/My Documents" I have not tried the snapshots, mainly because they are package differently and I'm not sure what to download. Does anyone know if this issue has been addressed? If so, what do I need to download? I would be happy if there were a way to disable the POSIX to WIN32 path name conversion, but I could not find it if it exists. Stu |
From: Keith M. <kei...@to...> - 2007-04-26 15:07:11
|
Group W wrote: > I noticed that in a shell script the path: > "C:/Documents and Settings/.../My Documents" > > is incorrectly being converted to: > "C;<msys installation dir>/Documents and Settings/.../My Documents" > > I have not tried the snapshots, mainly because they are package > differently and I'm not sure what to download. Does anyone know if > this issue has been addressed? If so, what do I need to download? It's a known bug, which only shows up occasionally, in particular contexts; (what is it, in full, in your case, BTW). AFAIK, no fix has yet been identified. > I would be happy if there were a way to disable the POSIX to WIN32 > path name conversion, but I could not find it if it exists. It has been mooted, in the past, but nothing is likely to materialise until MSYS-1.0.12. FWIW, with MSYS-1.0.11, I see: $ cmd //c echo "C:/Documents and Settings/keith/My Documents" "C:/Documents and Settings/keith/My Documents" $ ls "C:/Documents and Settings/keith/My Documents" My Pictures $ ls "C:/Documents and Settings/keith/My Documents/My Pictures" Desktop.ini Sample.jpg but, in a context I know to be problematic: $ cmd //c echo "dir C:/Documents and Settings/keith/My Documents" "dir C;D:\MSYS-1.0.11\Documents and Settings\keith\My Documents" Regards, Keith. |
From: Julien L. <ju...@fa...> - 2007-04-27 12:39:06
|
Keith MARSHALL wrote: > Group W wrote: >> I noticed that in a shell script the path: >> "C:/Documents and Settings/.../My Documents" >> >> is incorrectly being converted to: >> "C;<msys installation dir>/Documents and Settings/.../My Documents" >> > > It's a known bug, which only shows up occasionally, in particular > contexts; (what is it, in full, in your case, BTW). AFAIK, no fix > has yet been identified. > > FWIW, with MSYS-1.0.11, I see: > $ cmd //c echo "C:/Documents and Settings/keith/My Documents" > "C:/Documents and Settings/keith/My Documents" > > $ ls "C:/Documents and Settings/keith/My Documents" > My Pictures > > $ ls "C:/Documents and Settings/keith/My Documents/My Pictures" > Desktop.ini Sample.jpg > > but, in a context I know to be problematic: > > $ cmd //c echo "dir C:/Documents and Settings/keith/My Documents" > "dir C;D:\MSYS-1.0.11\Documents and Settings\keith\My Documents" > The builtin 'echo' of cmd.exe and bash behave differently: *cmd.exe:* > echo "Hello World" "Hello World" > echo Hello World Hello World *bash:* $ echo "Hello World" Hello World $ echo Hello World Hello World So in your first and last case; if you unquote the 'echo' passed to cmd; then you should get: $ cmd //c echo C:/Documents and Settings/Lecomte/Mes documents C:/Documents and Settings/Lecomte/Mes documents $ cmd //c echo dir C:/Documents and Settings/Lecomte/Mes documents dir C:/Documents and Settings/Lecomte/Mes documents I've hacked around the cmd shell script and got this to work with your 2 testcases: $(echo $COMSPEC | sed -e 's#\\#/#g') `echo "$@"` A couple explanations: - Using $(..) is because with backticks I get "sed: -e expression #2, char 7: Unterminated `s' command" - I've changed the sed because with the initial 's#\\\\#/#g' it doesn't convert the slashes. Is this deliberate? Am I missing something? - By issuing a backticked 'echo "$@"', we get the behavior of a cmd.exe 'echo. Julien |
From: Keith M. <kei...@to...> - 2007-04-27 13:44:52
|
Julien Lecomte wrote, quoting me: >> $ cmd //c echo "C:/Documents and Settings/keith/My Documents" >> "dir C;D:\MSYS-1.0.11\Documents and Settings\keith\My Documents" >> >> ... >> >> $ cmd //c echo "dir C:/Documents and Settings/keith/My Documents" >> "dir C;D:\MSYS-1.0.11\Documents and Settings\keith\My Documents" > > > The builtin 'echo' of cmd.exe and bash behave differently: > *cmd.exe:* > > > echo "Hello World" > "Hello World" > > > echo Hello World > Hello World > > *bash:* > > $ echo "Hello World" > Hello World > > $ echo Hello World > Hello World > > So in your first and last case; if you unquote the 'echo' passed to > cmd; then you should get: > > $ cmd //c echo C:/Documents and Settings/Lecomte/Mes documents > C:/Documents and Settings/Lecomte/Mes documents > > $ cmd //c echo dir C:/Documents and Settings/Lecomte/Mes documents > dir C:/Documents and Settings/Lecomte/Mes documents But the purpose of the example was to illustrate how MSYS incorrectly translates a string, with an embedded Win32 path name, prefixed by some other text, when it hands it off to a native program, (cmd.exe in this case). This is a known edge case, where MSYS is simply too clever for its own good: when it finds a string with text preceding the `C:/' it assumes that it represents a POSIX style `PATH=/colon/separated:/path', and converts it to the equivalent semicolon separated form. There seems to be no reliable way to avoid that, when it is not wanted. By removing the quotes, you destroy the intent of the example. Regards, Keith. |