enhanced version of cygpath

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

enhanced version of cygpath

Ralph Engels
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

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: enhanced version of cygpath

Earnie Boyd
On Sat, Apr 14, 2012 at 12:51 AM, ralph engels <[hidden email]> wrote:
> Just uploaded an enhanced version of cygpath that follows cygwins more

Cygpath will not be used.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: enhanced version of cygpath

Ralph Engels
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.




------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: enhanced version of cygpath

Earnie Boyd
On Sat, Apr 14, 2012 at 6:20 PM, ralph engels <[hidden email]> 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

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: enhanced version of cygpath

Ralph Engels
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



------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: enhanced version of cygpath

Charles Wilson-8
In reply to this post by Earnie Boyd
On 4/14/2012 7:10 PM, Earnie Boyd wrote:
> On Sat, Apr 14, 2012 at 6:20 PM, ralph engels<[hidden email]>  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.

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: enhanced version of cygpath

Ralph Engels
Ok thanks for the clarification :).
Well in case someone "does" need it its on my sourceforge site.

Ralph



------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: enhanced version of cygpath

Keith Marshall-3
In reply to this post by Charles Wilson-8
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.

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: enhanced version of cygpath

Ralph Engels
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



------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: enhanced version of cygpath

Charles Wilson-8
In reply to this post by Keith Marshall-3
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


------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: enhanced version of cygpath

Ralf Fassel
In reply to this post by Keith Marshall-3
* 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'

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: enhanced version of cygpath

Damon Register
In reply to this post by Keith Marshall-3
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



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: enhanced version of cygpath

Earnie Boyd
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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys