From: Noam P. <npo...@us...> - 2011-02-20 21:05:48
|
Hi, I'm trying to get the test suite for xmlstarlet to work under msys, and since it deals with xpath expressions that can start with "/" I need to defeat the path conversion that msys performs. The thing is, this feature seems underdocumented: the README.rtf only says that a doubled leading slash will protect the option from conversion, but it looks like there is bit more to it: $ cat args.c #include <stdio.h> int main(int argc, char **argv) { int i; for (i = 1; i < argc; i++) { printf("arg%d: %s\n", i, argv[i]); } return 0; } $ make args CC=gcc CFLAGS='-Wall -Wextra -ansi -pedantic' gcc -Wall -Wextra -ansi -pedantic args.c -o args $ ./args /foobar arg1: C:/MinGW/msys/1.0/foobar $ ./args //foobar # we can get /foobar arg1: /foobar $ ./args /foo/bar arg1: C:/MinGW/msys/1.0/foo/bar $ ./args //foo/bar # how can we get /foo/bar? arg1: //foo/bar $ ./args '/foo;bar' # a semicolon also stops conversion!? arg1: /foo;bar Is there more detailed documentation on this feature anywhere? thanks, Noam |
From: Keith M. <kei...@nt...> - 2011-02-20 22:08:43
|
On 20/02/11 21:05, Noam Postavsky wrote: > I need to defeat the path conversion that msys performs. The thing > is, this feature seems underdocumented: the README.rtf only says > that a doubled leading slash will protect the option from conversion, > but it looks like there is bit more to it: > > ...snip... > > $ ./args /foobar > arg1: C:/MinGW/msys/1.0/foobar This is correct, as documented. > $ ./args //foobar # we can get /foobar > arg1: /foobar Also correct. > $ ./args /foo/bar > arg1: C:/MinGW/msys/1.0/foo/bar Correct again. > $ ./args //foo/bar # how can we get /foo/bar? > arg1: //foo/bar This looks like a bug. I've been aware of some deficiencies in the MSYS path translation code for some time, but I can't recall having seen this particular manifestation before. Unfortunately, I don't have a Windows box here, to investigate further. > $ ./args '/foo;bar' # a semicolon also stops conversion!? > arg1: /foo;bar Yes, because the semicolon is Windows native path list separator. This is interpreted as a path list argument, which is already in the native Windows format, so no translation required. > Is there more detailed documentation on this feature anywhere? Short of studying the source code, none of which I am aware. -- Regards, Keith. |
From: Earnie <ea...@us...> - 2011-02-22 14:14:51
|
Keith Marshall wrote: > On 20/02/11 21:05, Noam Postavsky wrote: >> $ ./args //foo/bar # how can we get /foo/bar? > > arg1: //foo/bar > > This looks like a bug. I've been aware of some deficiencies in the MSYS > path translation code for some time, but I can't recall having seen this > particular manifestation before. Unfortunately, I don't have a Windows > box here, to investigate further. > This behaves properly as well as in //server/share. I don't think you can get the /foo/bar string in a native program as it is coded today. At one time //server/share became /server/share but the users complained so it was changed. -- Earnie -- http://www.for-my-kids.com |
From: Keith M. <kei...@us...> - 2011-02-22 15:35:13
|
On 22 February 2011 14:14, Earnie wrote: > Keith Marshall wrote: >> On 20/02/11 21:05, Noam Postavsky wrote: >>> $ ./args //foo/bar # how can we get /foo/bar? >> > arg1: //foo/bar >> >> This looks like a bug. I've been aware of some deficiencies in the MSYS >> path translation code for some time, but I can't recall having seen this >> particular manifestation before. Unfortunately, I don't have a Windows >> box here, to investigate further. > > This behaves properly as well as in //server/share. Huh? I've always understood that the correct way to specify a UNC style path, such as //server/share, to be passed from MSYS shell to any native application, is to add an extra slash, so it becomes ///server/share. You even said as much yourself, in your response to this ticket: https://sourceforge.net/tracker/?func=detail&aid=3091216&group_id=2435&atid=102435 > I don't think you can get the /foo/bar string in a native program as > it is coded today. You can't. As it is coded today, it is broken. In fact, it has always been broken (almost by definition), since it employs heuristic analysis; any such analysis will always be broken in some circumstance. We really need a deterministic mechanism for exempting certain parameters from path name translation. > At one time //server/share became /server/share but the users > complained so it was changed. //server/share becoming /server/share is documented behaviour. Users complaining about that should have been directed to RTFM; changing it for the benefit of such lusers has broken it, to the detriment of everyone else. -- Regards, Keith. |
From: Noam P. <npo...@us...> - 2011-03-14 02:08:08
|
Earnie <ea...@us...> writes: >> On 20/02/11 21:05, Noam Postavsky wrote: >>> $ ./args //foo/bar # how can we get /foo/bar? >>> arg1: //foo/bar > This behaves properly as well as in //server/share. I don't think you > can get the /foo/bar string in a native program as it is coded today. It turns out you can get /foo/bar with '//foo\bar'. This and other interesting examples are now up on the wiki: http://www.mingw.org/wiki/Posix_path_conversion Noam |
From: Earnie <ea...@us...> - 2011-03-14 12:40:45
|
Noam Postavsky wrote: > Earnie <ea...@us...> writes: >>> On 20/02/11 21:05, Noam Postavsky wrote: >>>> $ ./args //foo/bar # how can we get /foo/bar? >>>> arg1: //foo/bar >> This behaves properly as well as in //server/share. I don't think you >> can get the /foo/bar string in a native program as it is coded today. > > It turns out you can get /foo/bar with '//foo\bar'. This and other > interesting examples are now up on the wiki: > http://www.mingw.org/wiki/Posix_path_conversion > Can you please put a link to the page in the FAQ? Otherwise people might not be able to find it. I found some of the wording a bit confusing requiring me to read it more than once to understand it but I don't have time to spend to make it better. One thing I might consider would be removing the s following \ and / where you're trying to indicate plurality. That s definitely got in the way of what you were trying to convey. -- Earnie -- http://www.for-my-kids.com |
From: Noam P. <npo...@us...> - 2011-03-11 04:35:00
|
Keith Marshall <kei...@nt...> writes: >> Is there more detailed documentation on this feature anywhere? > > Short of studying the source code, none of which I am aware. So now that mingw.org is back online, I would like to suggest a wiki page documenting the current behaviour. I'm willing to write it up if someone can point me to the source files and create / give me permission to create the wiki page. Noam |
From: Noam P. <npo...@us...> - 2011-03-11 17:19:44
|
Earnie <ea...@us...> writes: > The source code can be find in CVS with instructions at the project page > on SF. I looked at the repository through the web interface but I couldn't find the code that implements the conversion. Also, the CVS instructions mention modulename but don't say what the possible module names are. > I can give you permissions for editing the wiki if you give me > your login name to mingw.org. It's npostavs. Noam |
From: Keith M. <kei...@us...> - 2011-03-11 22:21:55
|
On 11/03/11 17:19, Noam Postavsky wrote: >> The source code can be find in CVS with instructions at the >> project page on SF. > > I looked at the repository through the web interface but I couldn't > find the code that implements the conversion. It isn't easy to find, (because its location isn't exactly obvious): http://mingw.cvs.sourceforge.net/viewvc/mingw/msys/rt/src/winsup/cygwin/path.cc?view=log > Also, the CVS instructions mention modulename but don't say what > the possible module names are. If you mean the instructions here: http://sourceforge.net/scm/?type=cvs&group_id=2435 (which you reach by following the Develop->Code->CVS links from the menu bar on the Project pages), they tell you that you may deduce the module names by looking here: http://mingw.cvs.sourceforge.net/viewvc/mingw/ Each directory you see there represents a module; the module name is the same as the directory name. -- Regards, Keith. |
From: Earnie <ea...@us...> - 2011-03-12 15:05:30
|
Noam Postavsky wrote: > Earnie <ea...@us...> writes: >> I can give you permissions for editing the wiki if you give me >> your login name to mingw.org. > > It's npostavs. > You can now edit the wiki. -- Earnie -- http://www.for-my-kids.com |
From: Earnie <ea...@us...> - 2011-03-11 12:41:14
|
Noam Postavsky wrote: > Keith Marshall <kei...@nt...> writes: > >>> Is there more detailed documentation on this feature anywhere? >> >> Short of studying the source code, none of which I am aware. > > So now that mingw.org is back online, I would like to suggest a wiki > page documenting the current behaviour. I'm willing to write it up if > someone can point me to the source files and create / give me permission > to create the wiki page. > The source code can be find in CVS with instructions at the project page on SF. I can give you permissions for editing the wiki if you give me your login name to mingw.org. -- Earnie -- http://www.for-my-kids.com |
From: J D. <d3...@gm...> - 2011-03-14 22:16:19
|
//./ is 'this computer' did you try with a drive letter? ./args c:/foo/bar On Sun, Feb 20, 2011 at 1:05 PM, Noam Postavsky <npo...@us...> wrote: > Hi, > > I'm trying to get the test suite for xmlstarlet to work under msys, > and since it deals with xpath expressions that can start with "/" I > need to defeat the path conversion that msys performs. The thing is, > this feature seems underdocumented: the README.rtf only says that a > doubled leading slash will protect the option from conversion, but it > looks like there is bit more to it: > > $ cat args.c > #include <stdio.h> > > int main(int argc, char **argv) > { > int i; > for (i = 1; i < argc; i++) { > printf("arg%d: %s\n", i, argv[i]); > } > return 0; > } > > $ make args CC=gcc CFLAGS='-Wall -Wextra -ansi -pedantic' > gcc -Wall -Wextra -ansi -pedantic args.c -o args > $ ./args /foobar > arg1: C:/MinGW/msys/1.0/foobar > $ ./args //foobar # we can get /foobar > arg1: /foobar > $ ./args /foo/bar > arg1: C:/MinGW/msys/1.0/foo/bar > $ ./args //foo/bar # how can we get /foo/bar? > arg1: //foo/bar > $ ./args '/foo;bar' # a semicolon also stops conversion!? > arg1: /foo;bar > > Is there more detailed documentation on this feature anywhere? > > thanks, Noam > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > 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: Noam P. <npo...@us...> - 2011-03-15 00:55:47
|
On Mon, Mar 14, 2011 at 6:16 PM, J Decker <d3...@gm...> wrote: > //./ is 'this computer' Okay? > did you try with a drive letter? > > ./args c:/foo/bar I'm working with xpath expressions (http://www.w3.org/TR/xpath/), so adding a drive letter isn't really an option... |
From: Earnie <ea...@us...> - 2011-03-15 12:49:43
|
> On Sun, Feb 20, 2011 at 1:05 PM, Noam Postavsky wrote: >> Hi, >> >> I'm trying to get the test suite for xmlstarlet to work under msys, >> and since it deals with xpath expressions that can start with "/" I >> need to defeat the path conversion that msys performs. The thing is, >> this feature seems underdocumented: the README.rtf only says that a >> doubled leading slash will protect the option from conversion, but it >> looks like there is bit more to it: Some of the "bit more to it" may have come after the README.rtf was written and the README.rtf not updated with feature changes. >> >> $ cat args.c >> #include <stdio.h> >> >> int main(int argc, char **argv) >> { >> int i; >> for (i = 1; i < argc; i++) { >> printf("arg%d: %s\n", i, argv[i]); >> } >> return 0; >> } >> >> $ make args CC=gcc CFLAGS='-Wall -Wextra -ansi -pedantic' >> gcc -Wall -Wextra -ansi -pedantic args.c -o args >> $ ./args /foobar >> arg1: C:/MinGW/msys/1.0/foobar Which is correct. >> $ ./args //foobar # we can get /foobar >> arg1: /foobar Which is correct. >> $ ./args /foo/bar >> arg1: C:/MinGW/msys/1.0/foo/bar This is also correct. >> $ ./args //foo/bar # how can we get /foo/bar? >> arg1: //foo/bar This was a change to the original use of // to allow the representation of //server/share but I think we should use ///server/share instead so that //foo/bar can give /foo/bar. Cesar will have to make the final call since he is the current maintainer. I don't know of a workaround other than perhaps maybe string concatenation. >> $ ./args '/foo;bar' # a semicolon also stops conversion!? >> arg1: /foo;bar Since ; is a Windows path list delimiter a ; in the string will cause MSYS to think the string is already a windows path and therefore not do the conversion so this is correct as well. >> >> Is there more detailed documentation on this feature anywhere? >> Other than the source and your experimentation, no. -- Earnie -- http://www.for-my-kids.com |
From: Cesar S. <ces...@gm...> - 2011-03-19 17:23:48
|
On 03/15/2011 09:49 AM, Earnie wrote: >> On Sun, Feb 20, 2011 at 1:05 PM, Noam Postavsky wrote: >>> $ ./args //foo/bar # how can we get /foo/bar? >>> arg1: //foo/bar > > This was a change to the original use of // to allow the representation > of //server/share but I think we should use ///server/share instead so > that //foo/bar can give /foo/bar. Cesar will have to make the final > call since he is the current maintainer. Looks reasonable. Cesar |