From: ralph e. <ral...@gm...> - 2012-04-14 04:51:59
|
Just uploaded an enhanced version of cygpath that follows cygwins more closely. Only option missing is the mode switch for text or binary (not even sure if needed since the runtime "msys-1.0.dll" seem to check for that allready ?). Reason i made this is that i sometimes run into sources which croak at the missing mixed mode support so i have to patch those. Preliminary testing shows no problems, but if you run into something let me know. If you find it ok i allready made it part of the msys core sources and can upload it in case you want this. Also added ldd and kill to the msys core source and the source was modified so it now compiles with gcc4. Several other enhancements added also so building more recent stuff still possible with msys-1.0 with minimal hackery. Might keep it afloat untill Msys2 is ready. file here: http://sourceforge.net/projects/cbadvanced/files/Msys%20Specific/cygpath-enhanced.7z/download |
From: Earnie B. <ea...@us...> - 2012-04-14 16:57:56
|
On Sat, Apr 14, 2012 at 12:51 AM, ralph engels <ral...@gm...> wrote: > Just uploaded an enhanced version of cygpath that follows cygwins more Cygpath will not be used. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: ralph e. <ral...@gm...> - 2012-04-14 22:20:06
|
Hmm ok ? any reason in particular maybe plans to do what it does in code instead ? (the better solution). Im still working on a few things msys related but because of health issues im not on as much as i where before, but when time and and issues permit ill keep on it. Ralph. |
From: Earnie B. <ea...@us...> - 2012-04-14 23:10:16
|
On Sat, Apr 14, 2012 at 6:20 PM, ralph engels <ral...@gm...> wrote: > Hmm ok ? any reason in particular maybe plans to do what it does in code > instead ? (the better solution). > Im still working on a few things msys related but because of health > issues im not on as much as i where before, but > when time and and issues permit ill keep on it. Same reason we don't have it now; it's not needed. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: ralph e. <ral...@gm...> - 2012-04-15 00:06:12
|
We dont ?!? its part of the msyscore package atleast last i looked it was there. While id rather avoid it, it does have its uses but its up to you ofc. I only made this as it was allready part of msys. Ralph |
From: Charles W. <cwi...@us...> - 2012-04-15 03:35:46
|
On 4/14/2012 7:10 PM, Earnie Boyd wrote: > On Sat, Apr 14, 2012 at 6:20 PM, ralph engels<ral...@pu...> wrote: >> Hmm ok ? any reason in particular maybe plans to do what it does in code >> instead ? (the better solution). >> Im still working on a few things msys related but because of health >> issues im not on as much as i where before, but >> when time and and issues permit ill keep on it. > > Same reason we don't have it now; it's not needed. It is not *normally* needed thanks to MSYS's own auto-path-translation heuristics. However, when the heuristic fails -- and all heuristics do, at some point or other -- we don't actually provide *ANY* workaround at all, except "wait for a new MSYS dll with slightly improved heuristics". cygpath (msyspath?) would be the weapon of last resort, if it were available. This doesn't mean it automatically should be part of the distribution (even Contributed) -- maybe it's good enough that the weapon exists "somewhere" we can point the desparate to. But the tool needn't be dismissed out of hand. |
From: ralph e. <ral...@gm...> - 2012-04-15 06:32:06
|
Ok thanks for the clarification :). Well in case someone "does" need it its on my sourceforge site. Ralph |
From: Keith M. <kei...@us...> - 2012-04-15 07:46:49
|
On 15/04/12 04:35, Charles Wilson wrote: > On 4/14/2012 7:10 PM, Earnie Boyd wrote: >> On Sat, Apr 14, 2012 at 6:20 PM, ralph engels wrote: >>> Hmm ok ? any reason in particular ... >> >> Same reason we don't have it now; it's not needed. > > It is not *normally* needed thanks to MSYS's own auto-path-translation > heuristics. However, when the heuristic fails -- and all heuristics do, > at some point or other -- we don't actually provide *ANY* workaround at > all, except "wait for a new MSYS dll with slightly improved heuristics". We already know of scenarios where the heuristics fail -- usually as a result of over-aggressive interpretation of a string, which the user intends to be interpreted literally, being misinterpreted as a path, or a path list, and thus being "helpfully" converted into something which is entirely inappropriate. There have been suggestions, in the past, for circumventing this; they range from use of an environment variable providing a blanket on/off switching mechanism for MSYS path conversion heuristics -- not very useful, IMO -- to a more selective approach employing a particular prefix, which itself could be specified via the environment, and which would mark the following string as exempt from any conversion, (beyond removal of the first instance of the prefix itself). However, until someone actually makes an effort -- finds a tuit -- to implement any such strategy, it's all just so much pie in the sky. > cygpath (msyspath?) would be the weapon of last resort, if it were > available. But, would cygpath -- I would prefer it to be renamed as msyspath -- actually help, in any of the scenarios already identified as current failure cases? I may be wrong, but I suspect that it wouldn't; surely any path string emitted by this msyspath, on subsequently passing it as an argument to a native application, would still end up being scrambled by the built-in heuristics? > This doesn't mean it automatically should be part of the distribution > (even Contributed) ... Agreed. > -- maybe it's good enough that the weapon exists "somewhere" we can > point the desparate to. But the tool needn't be dismissed out of > hand. Of course not, but like Earnie, I'm having a hard time seeing any scenario in which it might actually be helpful. -- Regards, Keith. |
From: ralph e. <ral...@gm...> - 2012-04-15 10:52:43
|
Cant say i found a lot of cases but python atleast atm uses cygpath since its derived from a cygwin port. I hope to remove that in future builds though. Graphviz is also a huge pain to build without it. So while not needed as part of msys i dont see a problem with it as a contrib tool as in some cases it has its uses. The best solution ofc. would be that the need for it (however rare that is) would be removed. Ralph |
From: Charles W. <cwi...@us...> - 2012-04-15 20:14:11
|
On 4/15/2012 3:46 AM, Keith Marshall wrote: > Of course not, but like Earnie, I'm having a hard time seeing any > scenario in which it might actually be helpful. As ralph mentioned (his msys-python), I think the most common case would be "half-ported" packages that are themselves msys, but expect win32 path handling for some reason. Obviously, the Right Thing To Do is to fix those apps -- but, as the 15 year history of cygwin's tcl/tk package shows, sometimes "half-ported" persists for a long time (FWIW, my not-yet-complete msys-tcl/tk is "fully ported" to msys in this respect). Also, such a capability would have helped libtool -- since it is an "MSYS" script which needs to generate source code for a native w32 C-wrapper that contains embedded win32 paths. It currently uses the following: # awkward: cmd appends spaces to result func_convert_core_msys_to_w32_result=`( cmd //c echo "$1" ) 2>/dev/null | $SED -e 's/[ ]*$//' -e "$lt_sed_naive_backslashify"` -- Chuck |
From: Ralf F. <ra...@gm...> - 2012-04-16 08:55:23
|
* Keith Marshall | But, would cygpath -- I would prefer it to be renamed as msyspath -- | actually help, in any of the scenarios already identified as current | failure cases? I may be wrong, but I suspect that it wouldn't; surely | any path string emitted by this msyspath, on subsequently passing it as | an argument to a native application, would still end up being scrambled | by the built-in heuristics? We called it as last resort from a win32 application using popen(), thus reading the output directly inside the win32 app. We used an 'enhanced' cygpath version anyway (merge between cygwin and msys switches), but I'd definitely vote for 'keep'. My EUR 0.01 R' |
From: Damon R. <dam...@lm...> - 2012-07-28 16:11:11
|
On 4/15/2012 3:46 AM, Keith Marshall wrote: > We already know of scenarios where the heuristics fail -- usually as a > result of over-aggressive interpretation of a string, which the user > intends to be interpreted literally, being misinterpreted as a path, or > a path list, and thus being "helpfully" converted into something which > is entirely inappropriate. I am currently trying to build a working libxml2-2.8.0 and am having a problem I believe to be a compiler bug. I am wondering if this failure you mention above is what I am seeing. I even created a simple console hello world type of app that does nothing but print out the args passed to the program. I am finding that this argument "-//OASIS//DTD DocBook XML V4.3//EN" is getting mangled to -/C:/MinGW/msys/1.0/OASIS/DTD DocBook XML V4.3/EN Is this the kind of fail you mean? > Of course not, but like Earnie, I'm having a hard time seeing any > scenario in which it might actually be helpful. I am having an even harder time following. What is the current solution to deal with this problem? Damon Register |
From: Earnie B. <ea...@us...> - 2012-07-28 17:02:54
|
On Sat, Jul 28, 2012 at 10:16 AM, Damon Register wrote: > On 4/15/2012 3:46 AM, Keith Marshall wrote: >> We already know of scenarios where the heuristics fail -- usually as a >> result of over-aggressive interpretation of a string, which the user >> intends to be interpreted literally, being misinterpreted as a path, or >> a path list, and thus being "helpfully" converted into something which >> is entirely inappropriate. > I am currently trying to build a working libxml2-2.8.0 and am having > a problem I believe to be a compiler bug. I am wondering if this failure > you mention above is what I am seeing. I even created a simple console > hello world type of app that does nothing but print out the args passed > to the program. I am finding that this argument > "-//OASIS//DTD DocBook XML V4.3//EN" > is getting mangled to > -/C:/MinGW/msys/1.0/OASIS/DTD DocBook XML V4.3/EN > > Is this the kind of fail you mean? > Yes. >> Of course not, but like Earnie, I'm having a hard time seeing any >> scenario in which it might actually be helpful. > I am having an even harder time following. What is the current solution > to deal with this problem? Instead of "-//OASIS//DTD DocBook XML V4.3//EN" Use "-///OASIS///DTD DocBook XML V4.3///EN" The above is untested but you should be able to use /// to get a // string without MSYS doing anything other than removing one /. -- Earnie -- https://sites.google.com/site/earnieboyd |