From: BGINFO f. X <bgi...@kz...> - 2013-02-08 15:27:56
|
Hello everyone, After reading some documentation about PATHS, http://www.mingw.org/wiki/Posix_path_conversion I have some problems doing a trivial "ls" with windows paths (no spaces). I have done 5 tests: 1) Windows path one folder - It works! $ ls -la c:\windows ls: c:windows/CSC: total 23080 drwxr-xr-x 64 k Administradores 28672 Jan 18 19:48 . drwxsr-xr-x 22 k Administradores 16384 Feb 6 16:38 .. -rw-r--r-- 1 k Administradores 5242934 Nov 5 08:30 BGInfo.bmp ... 2) POSIX path one folder -> It works! $ ls -la c:/windows ls: c:/windows/CSC: total 23080 drwxr-xr-x 64 k Administradores 28672 Jan 18 19:48 . drwxr-xr-x 22 k Administradores 16384 Feb 6 16:38 .. -rw-r--r-- 1 k Administradores 5242934 Nov 5 08:30 BGInfo.bmp ... 3) POSIX path subfolder (ADAM) -> It works! $ ls -la c:/windows/ADAM total 3384 drwxr-xr-x 37 k Administradores 4096 Mar 20 2012 . drwxr-xr-x 64 k Administradores 28672 Jan 18 19:48 .. -rwxr-xr-x 2 k Administradores 253952 Nov 20 2010 ADSchemaAnalyzer.exe ... 4) Windows path subfolder (ADAM) -> It doesn't works! $ ls -la c:\windows\ADAM ls: c:windowsADAM: No such file or directory 5) Windows path subfolder (ADAM) QUOTED -> It works! $ ls -la "c:\windows\ADAM" total 3384 drwxr-xr-x 37 k Administradores 4096 Mar 20 2012 . drwxr-xr-x 64 k Administradores 28672 Jan 18 19:48 .. -rwxr-xr-x 2 k Administradores 253952 Nov 20 2010 ADSchemaAnalyzer.exe My question is: Why test 4 doesn't work? If there is only one folder, it works (test 1). I don't understand why adding subfolders fails. Is there any reason? I'm doing something wrong? Why test 5 works? I think that quoting here is not necessary. But In fact I don't mind if works with quotes. My real question is test 4. Thanks a lot. |
From: Eli Z. <el...@gn...> - 2013-02-08 15:49:50
|
> Date: Fri, 8 Feb 2013 16:27:49 +0100 > From: BGINFO for X <bgi...@kz...> > > 4) Windows path subfolder (ADAM) -> It doesn't works! > > $ ls -la c:\windows\ADAM > > ls: c:windowsADAM: No such file or directory The backslash is an escape character in Unix shells, so to get a literal backslash you need to double them: ls -la c:\\windows\\ADAM (Not that I understand why you would like to use backslashes in a Unix shell.) > Why test 5 works? Because quotes prevent backslashes from being interpreted as escape characters. |
From: Renato S. <br....@gm...> - 2013-02-08 16:14:55
|
2013/2/8 Eli Zaretskii <el...@gn...> > The backslash is an escape character in Unix shells, so to get a > literal backslash you need to double them: > > ls -la c:\\windows\\ADAM > > (Not that I understand why you would like to use backslashes in a Unix > shell.) > BGINFO for X, do you realize you can use forward slashes instead? For example: ls -la /c/windows/ADAM (Unix style) ls -la c:/windows/ADAM (recognized by Windows -- explorer, cmd.exe, etc). |
From: BGINFO f. X <bgi...@kz...> - 2013-02-08 16:04:59
|
Yes, I was a little confused because 1) Windows path one folder - works! $ ls -la c:\windows .... list of files .... Because it is scaping w, the resulting command is : ls -la c:windows , that in my opinion shouldn't work. But it works. For example, in cygwin ls -la c.\windows returns: couldn't access to c:windows, no such file or directory. In windows dir c:windows return no such file or directory. Do you know what I mean? Is this a bug? Thanks to all. 2013/2/8 Eli Zaretskii <el...@gn...> > > Date: Fri, 8 Feb 2013 16:27:49 +0100 > > From: BGINFO for X <bgi...@kz...> > > > > 4) Windows path subfolder (ADAM) -> It doesn't works! > > > > $ ls -la c:\windows\ADAM > > > > ls: c:windowsADAM: No such file or directory > > The backslash is an escape character in Unix shells, so to get a > literal backslash you need to double them: > > ls -la c:\\windows\\ADAM > > (Not that I understand why you would like to use backslashes in a Unix > shell.) > > > Why test 5 works? > > Because quotes prevent backslashes from being interpreted as escape > characters. > > > ------------------------------------------------------------------------------ > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list > etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe > |
From: Earnie B. <ea...@us...> - 2013-02-08 16:31:27
|
On Fri, Feb 8, 2013 at 11:04 AM, BGINFO for X <bgi...@kz...> wrote: Do not top post. > Yes, > > I was a little confused because 1) Windows path one folder - works! > > $ ls -la c:\windows > > .... list of files .... > > Because it is scaping w, the resulting command is : > ls -la c:windows , that in my opinion shouldn't work. But it works. > > For example, in cygwin ls -la c.\windows returns: > couldn't access to c:windows, no such file or directory. > > In windows dir c:windows return no such file or directory. Because your current working directory is not the root of the device specified. c: cd \ dir c:windows This will give you a directory listing c: cd \windows dir c:windows This will give you an error stating that it cannot find the directory. > > Do you know what I mean? Is this a bug? No this is not a bug, it is a feature of the OS. c:path is a shortcut for meaning the current working directory of the device specified and in this case C:. Trim the cruft. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Renato S. <br....@gm...> - 2013-02-08 16:21:57
|
2013/2/8 BGINFO for X <bgi...@kz...> > Because it is scaping w, the resulting command is : > ls -la c:windows , that in my opinion shouldn't work. But it works. > I agree, I see this as a bug too, for example: $ ls C:\programs\Java => ls: C:programsJava: No such file or directory $ ls C:\programs => shouldn't work, but give the same kind of error as above. |
From: Renato S. <br....@gm...> - 2013-02-08 16:37:58
|
2013/2/8 Renato Silva <br....@gm...> > 2013/2/8 BGINFO for X <bgi...@kz...> > >> Because it is scaping w, the resulting command is : >> ls -la c:windows , that in my opinion shouldn't work. But it works. >> > > I agree, I see this as a bug too, for example: > $ ls C:\programs\Java => ls: C:programsJava: No such file or directory > $ ls C:\programs => shouldn't work, but give the same kind of error as > above. > Actually mine is a separate issue, since your example is without backslashes. |
From: Earnie B. <ea...@us...> - 2013-02-08 16:34:44
|
On Fri, Feb 8, 2013 at 11:21 AM, Renato Silva <br....@gm...> wrote: > 2013/2/8 BGINFO for X <bgi...@kz...> >> >> Because it is scaping w, the resulting command is : >> ls -la c:windows , that in my opinion shouldn't work. But it works. > > > I agree, I see this as a bug too, for example: > $ ls C:\programs\Java => ls: C:programsJava: No such file or directory > $ ls C:\programs => shouldn't work, but give the same kind of error as > above. cd /c/programs ls c:Java It works as designed by the OS vendor. I don't think MSYS should do anything special here. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Renato S. <br....@gm...> - 2013-02-08 16:39:34
|
2013/2/8 Earnie Boyd <ea...@us...> > cd /c/programs > ls c:Java > > It works as designed by the OS vendor. I don't think MSYS should do > anything special here. > I mean with the backslash: ls c:\programs shouldn't work but it does. |
From: Earnie B. <ea...@us...> - 2013-02-08 19:18:41
|
On Fri, Feb 8, 2013 at 11:38 AM, Renato Silva wrote: > 2013/2/8 Earnie Boyd >> >> cd /c/programs >> ls c:Java >> >> It works as designed by the OS vendor. I don't think MSYS should do >> anything special here. > > > I mean with the backslash: ls c:\programs shouldn't work but it does. Yes, it is working properly. Bash converts \p to p and c:programs stats because of the way the OS handles it. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Renato S. <br....@gm...> - 2013-02-08 19:40:29
|
2013/2/8 Earnie Boyd <ea...@us...> > Yes, it is working properly. Bash converts \p to p and c:programs > stats because of the way the OS handles it. > But in the case of ls it seems to never care what the current directory is: $ cd /c/Windows $ cmd //c dir c:windows => path not found $ ls c:windows => doesn't care about the current directory |
From: Earnie B. <ea...@us...> - 2013-02-08 21:29:42
|
On Fri, Feb 8, 2013 at 2:39 PM, Renato Silva <br....@gm...> wrote: > 2013/2/8 Earnie Boyd <ea...@us...> >> >> Yes, it is working properly. Bash converts \p to p and c:programs >> stats because of the way the OS handles it. > > > But in the case of ls it seems to never care what the current directory is: > > $ cd /c/Windows > $ cmd //c dir c:windows => path not found For me this command states "File not found" but before that it states the directory is that of the MSYS bin directory. However if I cd /c and then issue the cmd command it will list the contents of the windows directory. > $ ls c:windows => doesn't care about the current directory Confirmed it is giving a directory listing of the Windows directory regardess of the CWD of the device. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Keith M. <kei...@us...> - 2013-02-08 21:39:38
|
On 08/02/13 19:18, Earnie Boyd wrote: [MSYS ls maps c:foo as c:/foo, regardless of current directory] > Yes, it is working properly. Bash converts \p to p and c:programs > stats because of the way the OS handles it. I disagree. This claim does not withstand scrutiny... $ cd $ cmd //c cd C:\MinGW\msys\1.0\home\keith $ cmd //c dir c:users Volume in drive C has no label. Volume Serial Number is 2038-1EBE Directory of C:\MinGW\msys\1.0\home\keith File Not Found $ ls c:users All Users Default Default User Guest Public desktop.ini keith IMO, this is not working correctly; the latter two commands *should* produce (effectively) the same result, i.e. if it does work the way the OS handles it, c:users should map to the *current* directory on drive c:, (not to the root of drive c:), yielding... $ ls c:users ls: c:users: No such file or directory -- Regards, Keith. |
From: Earnie B. <ea...@us...> - 2013-02-09 17:40:40
|
On Fri, Feb 8, 2013 at 4:39 PM, Keith Marshall wrote: > On 08/02/13 19:18, Earnie Boyd wrote: > [MSYS ls maps c:foo as c:/foo, regardless of current directory] >> Yes, it is working properly. Bash converts \p to p and c:programs >> stats because of the way the OS handles it. > > I disagree. This claim does not withstand scrutiny... > > $ cd > > $ cmd //c cd > C:\MinGW\msys\1.0\home\keith > > $ cmd //c dir c:users > Volume in drive C has no label. > Volume Serial Number is 2038-1EBE > > Directory of C:\MinGW\msys\1.0\home\keith > > File Not Found > > $ ls c:users > All Users Default Default User Guest Public desktop.ini keith > > IMO, this is not working correctly; the latter two commands *should* > produce (effectively) the same result, i.e. if it does work the way the > OS handles it, c:users should map to the *current* directory on drive > c:, (not to the root of drive c:), yielding... > > $ ls c:users > ls: c:users: No such file or directory I later stated it was broken. I'm guessing MSYS path translation is somehow getting in the way but one needs to follow the MSYS debug steps to find the issue. However my statements for D:Path as it concerns the OS is correct, it is a relative path to mean the CWD of the specified device. MSYS however is somehow modifying CWD without returning it to the previous CWD. BTW, you might want to use cmd.exe instead of cmd in your tests to exclude the use of shell script. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: BGINFO f. X <bgi...@kz...> - 2013-02-10 22:19:16
|
Hello everyone, Renato: I realized that I can use forward slashes instead. But the issue here is that I get the windows path from registry: reg query " .... " -> returns c:\Windows\Adm The best solution (I think) is something similar to cygpath, because then you can convert from Windows to POSIX without the need to escape the backslash. Keith: Yes, I agree with your tests. My tests are: ############## With backslash 1- MSDOS : OK -> results as expected c:\users\k -> dir c:\windows -> list of files c:\ -> dir c:\windows -> list of files h:\ -> dir c:\windows -> list of files h:\test -> dir c:\windows -> list of files 2- MINGW -> NO OK in my opinion. See test 4.1 c:\users\k -> ls c:\windows -> list of files (It shouldn't, I'm not in the root of the drive) c:\ -> ls c:\windows -> list of files h:\ -> ls c:\windows -> list of files h:\test -> ls c:\windows -> list of files 3- CYGWIN : OK in my opinion. -> always consistent. c:\users\k -> ls c:\windows -> c:windows: No such file or directory c:\ -> ls c:\windows -> c:windows: No such file or directory h:\ -> ls c:\windows -> c:windows: No such file or directory h:\test -> ls c:\windows -> c:windows: No such file or directory ########### Without backslash 4- MSDOS : 4.1 has no sense for me, but I agree with Earnie that it is a OS "feature". 4-1 c:\users\k -> dir c:windows -> no such file or directory c:\ -> dir c:windows -> list of files h:\ -> dir c:windows -> list of files h:\test -> dir c:windows -> list of files 5- MINGW : c:\users\k -> ls c:windows -> list of files -> no OK in my opinion , not the same result as 4.1 c:\ -> ls c:windows -> list of files h:\ -> ls c:windows -> list of files h:\test -> ls c:windows -> list of files 6- CYGWIN: OK in my opinion. -> always consistent. c:\users\k -> ls c:windows -> c:windows: No such file or directory c:\ -> ls c:windows -> c:windows: No such file or directory h:\ -> ls c:windows -> c:windows: No such file or directory h:\test -> ls c:windows -> c:windows: No such file or directory What do you think? Can you help me? Thanks a lot. 2013/2/9 Earnie Boyd <ea...@us...> > On Fri, Feb 8, 2013 at 4:39 PM, Keith Marshall wrote: > > On 08/02/13 19:18, Earnie Boyd wrote: > > [MSYS ls maps c:foo as c:/foo, regardless of current directory] > >> Yes, it is working properly. Bash converts \p to p and c:programs > >> stats because of the way the OS handles it. > > > > I disagree. This claim does not withstand scrutiny... > > > > $ cd > > > > $ cmd //c cd > > C:\MinGW\msys\1.0\home\keith > > > > $ cmd //c dir c:users > > Volume in drive C has no label. > > Volume Serial Number is 2038-1EBE > > > > Directory of C:\MinGW\msys\1.0\home\keith > > > > File Not Found > > > > $ ls c:users > > All Users Default Default User Guest Public desktop.ini keith > > > > IMO, this is not working correctly; the latter two commands *should* > > produce (effectively) the same result, i.e. if it does work the way the > > OS handles it, c:users should map to the *current* directory on drive > > c:, (not to the root of drive c:), yielding... > > > > $ ls c:users > > ls: c:users: No such file or directory > > I later stated it was broken. I'm guessing MSYS path translation is > somehow getting in the way but one needs to follow the MSYS debug > steps to find the issue. > > However my statements for D:Path as it concerns the OS is correct, it > is a relative path to mean the CWD of the specified device. MSYS > however is somehow modifying CWD without returning it to the previous > CWD. > > BTW, you might want to use cmd.exe instead of cmd in your tests to > exclude the use of shell script. > > -- > Earnie > -- https://sites.google.com/site/earnieboyd > > > ------------------------------------------------------------------------------ > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list > etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe > |
From: Earnie B. <ea...@us...> - 2013-02-11 12:37:20
|
On Sun, Feb 10, 2013 at 5:12 PM, BGINFO for X wrote: PLEASE DO NOT TOP POST! See http://www.mingw.org/lists.shtml > The best solution (I think) is something similar to cygpath, > because then you can convert from Windows to POSIX without the need to > escape the backslash. I don't think this is the best solution. I tried my hardest not to have this. You can use ``cd mypath && pwd -W'' in the bash shell to get the windows equivalent. The coreutils version needs patched, see https://sourceforge.net/p/mingw/bugs/1554/ for the issue, so you cannot (at the moment) use /bin/pwd for the -W option. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Renato S. <br....@gm...> - 2013-02-11 16:36:43
|
2013/2/11 Earnie Boyd <ea...@us...> > I don't think this is the best solution. I tried my hardest not to have > this. > > You can use ``cd mypath && pwd -W'' in the bash shell to get the > windows equivalent. The coreutils version needs patched, see > https://sourceforge.net/p/mingw/bugs/1554/ for the issue, so you > cannot (at the moment) use /bin/pwd for the -W option. > I also thought of Keith's winpath, but BGINFO for X actually wants the opposite, converting from Windows to Unix. Pwd without -W could work, but the same restrictions pointed out in the other thread that led to the writing of winpath, and that I don't remember well, still applies here. For example, the directory retrieved from registry should exist in order to switch to that directory for then running pwd. |
From: BGINFO f. X <bgi...@kz...> - 2013-02-11 18:02:18
|
> You can use ``cd mypath && pwd -W'' in the bash shell to get the > windows equivalent. The coreutils version needs patched, see > https://sourceforge.net/p/mingw/bugs/1554/ for the issue, so you > cannot (at the moment) use /bin/pwd for the -W option. > I also thought of Keith's winpath, but BGINFO for X actually wants the opposite, > converting from Windows to Unix. Pwd without -W could work, but the same > restrictions pointed out in the other thread that led to the writing of winpath, and > that I don't remember well, still applies here. For >example, the directory retrieved > from registry should exist in order to switch to that directory >for then running pwd. 1) But, we have found a bug (case 4.1) ? If yes, do I need to do something now? email to someone to communicate it? 2) I get this value from registry -> c:\Windows\Adam Then I need to check if the folder exist. If the folder doesn't exist, then I can't "cd mypath && pwd -W" or "cd mypath && echo $PWD". So it is no possible to get the $PWD in forward slashes like c:/Windows/Adam. What do you think? Thanks to all. |
From: Keith M. <kei...@us...> - 2013-02-11 17:58:16
|
On 09/02/13 17:40, Earnie Boyd wrote: > However my statements for D:Path as it concerns the OS is correct, it > is a relative path to mean the CWD of the specified device. MSYS > however is somehow modifying CWD without returning it to the previous > CWD. Sorry. I don't understand the significance, within the context of the current discussion, of the point you are trying to make. Certainly:-- * The MS-Windows OS, bedevilled by its fragmented multiple-device file system implementation, must maintain a current directory context per process, for each separate device; it must also maintain a current drive context for each process. * POSIX/Unix systems, having a logically homogeneous representation of the file system hierarchy, need only to maintain per process current directory context, (one item per process); there is no concept of a current drive, nor of current directory context for *any* device. * MSYS emulates the POSIX behaviour, but on the MS-Windows OS platform. Thus, the MSYS *logical* concept of current working directory *must* be a hybrid representation of current drive context *and* current working directory context on current drive, as maintained by the OS. * To appropriately support this emulation, MSYS shell's "cd" command must invoke *both* of the OS's "set current drive", *and* its "set current directory" services; thus, on start up, when MSYS shell is placed in its default current directory, by cd $HOME (which in my case represents "C:/MinGW/msys/1.0/home/keith"), then the OS context for the shell process will have been set such that current drive = C: current directory (on drive C:) = /MinGW/msys/1.0/home/keith * When the OS is requested to perform *any* operation on "d:pathname", "pathname" is interpreted *relative* to the current working directory context on drive "d:", (as maintained by the OS). * Conversely, when performing OS operations on "d:/pathname", (or on "d:\pathname"), the current working directory context is ignored, and "pathname" is interpreted as an *absolute* path, from the root of drive "d:". The examples I've offered previously illustrate correct interpretation of OS context, when processed by OS commands; they also illustrate that MSYS commands, (well, "ls" anyway), seem to interpret "d:pathname" as if it had been specified as "d:/pathname"; to me, (and you now appear to agree), this seems like a bug in MSYS. However, I see no evidence to support the claim that "MSYS is somehow modifying CWD, and failing to return to previous CWD". -- Regards, Keith. |
From: Renato S. <br....@gm...> - 2013-02-11 20:47:44
|
2013/2/11 Keith Marshall <kei...@us...> > The examples I've offered previously illustrate correct interpretation > of OS context, when processed by OS commands; they also illustrate that > MSYS commands, (well, "ls" anyway), seem to interpret "d:pathname" as if > it had been specified as "d:/pathname"; to me, (and you now appear to > agree), this seems like a bug in MSYS. However, I see no evidence to > support the claim that "MSYS is somehow modifying CWD, and failing > to return to previous CWD". > We have at least four people confirming this behavior of ls (BGINFO for X, Earnie, you and me). I would just take a look at the source code of ls, but my guess is that ls is either appending a slash/backslash to the colon when effectively using the WinAPI to retrieve the content of the directory, or it is indeed changing the current working directory for the corresponding drive when listing the contents or when the program is started. Below are a few tests of mine though, they confirm the problem once more, and show that msls <http://utools.com/msls.asp> does not share the same problem. /c/Users/Renato/Desktop $ cd .. /c/Users/Renato $ ls c:Desktop => should work but doesn't /c/Users/Renato $ cmd //c dir c:Desktop => works as expected /c/Users/Renato $ msls c:Desktop => works as expected 2013/2/11 BGINFO for X <bgi...@kz...> > 1) But, we have found a bug (case 4.1) ? If yes, do I need to do something > now? email to someone to communicate it? > I think it is rather the 5th item below, no? We have found a bug but it's not related to what you want. I think you just need a Windows-to-Unix path converter, right? I'd personally search for one, maybe write one myself, or just request it through the SourceForge bug tracker. 5- MINGW: c:\users\k -> ls c:windows -> list of files -> no OK in my > opinion , not the same result as 4.1 > > 2) I get this value from registry -> c:\Windows\Adam. Then I need to check > if the folder exist. If the folder doesn't exist, then I can't "cd mypath > && pwd -W" or "cd mypath && echo $PWD". So it is no possible to get the > $PWD in forward slashes like c:/Windows/Adam. I think you mean pwd without -W. I don't understand your question, but yes, pwd is no help if you can't cd to the directory. Just out of curiosity, what are you trying to achieve exactly? For example, is c:\Windows\Adam just an example or the real path that you need for some reason to convert to Unix style? |
From: BGINFO f. X <bgi...@kz...> - 2013-02-12 16:52:37
|
> I think it is rather the 5th item below, no? We have found a bug but it's not related > to what you want. I think you just need a Windows-to-Unix path converter, right? I'd > personally search for one, maybe write one myself, or just request it through the > SourceForge bug tracker. Yes, point 5th. Yes, the bug itself is not releted to what I want: a WIN32 - POSIX converter. I will requet one on bug tracker if We ALL agree with the definition of the bug. My points here: CMD.EXE: C:\>cd Users C:\Users>dir c:windows Directory of C:\Users No such file MSYS: $ cd c:\Users $ ls c:windows List of files ... But, Why we think that the bug is in ls-MSYS and not in dir-CMD.exe? I don't know, can anyone explain it to me? ########### Without backslash CMD.EXE (not always consistent: 4.1) : 4.1 c:\users\k -> dir c:windows -> no such file or directory 4.2 c:\ -> dir c:windows -> list of files 4.3 h:\ -> dir c:windows -> list of files 4.4 h:\test -> dir c:windows -> list of files ########### Without backslash CMD.EXE - MINGW (always consistent): c:\users\k -> ls c:windows -> list of files c:\ -> ls c:windows -> list of files h:\ -> ls c:windows -> list of files h:\test -> ls c:windows -> list of files At least MSYS is always consistent, always returns the list of files (CMD.exe not) > What are you trying to achieve exactly? For example, is c:\Windows\Adam just an > example or the real path that you need for some reason to convert to Unix style? Yes, it is a real example. What I'm trying to do is very simple (copy and paste a file to a win32 path), but I have some bug somewhere that pointed to me to the this bug that we are talking. If I found something more I will post it. Thanks to all. |
From: Renato S. <br....@gm...> - 2013-02-12 17:33:10
|
2013/2/12 BGINFO for X <bgi...@kz...> > But, Why we think that the bug is in ls-MSYS and not in dir-CMD.exe? > I don't know, can anyone explain it to me? > Earnie explained earlier it's a Windows feature. What are you trying to achieve exactly? For example, is c:\Windows\Adam >> just an > example or the real path that you need for some reason to convert >> to Unix style? >> > > Yes, it is a real example. What I'm trying to do is very simple (copy and > paste a file to a win32 path), but I have some bug somewhere that pointed > to me to the this bug that we are talking. If I found something more I will > post it. > I just forgot that your initial issue was with quotes, not really backslashes. And you have already posted a good solution yourself at the very beginning, which is just quoting your path. Something like this: path=$(reg query <params>) your_operation "$path" |
From: BGINFO4X <bgi...@kz...> - 2013-02-12 19:16:53
|
> > Earnie explained earlier it's a Windows feature. > Yes, Earnie explained it. But look at this: ########### Without backslash CMD.EXE (not always consistent: 4.1) : 4.1 c:\users\k -> dir c:windows -> no such file or directory 4.2 c:\ -> dir c:windows -> list of files 4.3 h:\ -> dir c:windows -> list of files 4.4 h:\test -> dir c:windows -> list of files See that 4.4 is not in the root of the current working directory of the device specified (as Earnie said) , and works equally. For me it shouldn't work, and you should get the same result as 4.1 I'm right? Thanks a lot . |
From: Keith M. <kei...@us...> - 2013-02-12 20:22:19
|
On 12/02/13 19:16, BGINFO4X wrote: > But look at this: > > ########### Without backslash CMD.EXE (not always consistent: 4.1) : Yes, it is; it behaves *exactly* as documented. > 4.1 c:\users\k -> dir c:windows -> no such file or directory Here, your current working directory on drive C: is \users\k, and there is no directory c:\users\k\windows; you've asked dir to list the content of the windows directory relative to current working directory on drive C:, which would be that non-existent c:\users\k\windows > 4.2 c:\ -> dir c:windows -> list of files Now you've changed current working directory on drive C: to c:\, and the directory c:\windows *does* exist. > 4.3 h:\ -> dir c:windows -> list of files Here, you've changed current *drive* to H:; current working directory on drive C: remains at C:\, and current working directory on drive H: is (apparently) H:\. You've asked dir to display the content of the windows directory relative to C:\, which of course still exists. > 4.4 h:\test -> dir c:windows -> list of files Now you've changed current working directory on drive H: to h:\test; current working directory on drive C: remains at C:\, and you've again asked dir to display the content of windows relative to C:\; it still exists, so there is nothing unexpected here. > See that 4.4 is not in the root of the current working directory of the > device specified (as Earnie said) , and works equally. Wrong. Current working directory on drive C: is still C:\, so dir displays the content of c:\windows, as it should. > For me it shouldn't work, and you should get the same result as 4.1 > > I'm right? No. Please read *my* post of last night again; it explains all of this in excruciating detail. If you still can't understand it, after you've read that again, then we are all wasting our time. -- Regards, Keith. |
From: BGINFO4X <bgi...@kz...> - 2013-02-12 20:48:43
|
> 4.4 h:\test -> dir c:windows -> list of files > > Now you've changed current working directory on drive H: to h:\test; > current working directory on drive C: remains at C:\, and you've again > asked dir to display the content of windows relative to C:\; it still > exists, so there is nothing unexpected here. > > > See that 4.4 is not in the root of the current working directory of the > > device specified (as Earnie said) , and works equally. > > Wrong. Current working directory on drive C: is still C:\, so dir > displays the content of c:\windows, as it should. > > Please read *my* post of last night again; it explains all of this > in excruciating detail. If you still can't understand it, after you've > read that again, then we are all wasting our time. > > Hello, After reading *your* post of last night, and with this graphical explanation, now it is clear for me. Thanks a lot. My level of operating systems and my level of English (makes more difficult the comprehension) isn't yours: I'm sorry. Thanks a lot again. |