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:
> 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