Re: enhanced version of cygpath

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