UNC and POSIX paths

[Larry Hall (Cygwin)]

On 6/17/2013 1:54 PM, gmt@malth.us wrote:
> On Mon, 17 Jun 2013, at 10:07, Andrew DeFaria thusly quipped:
>> On 06/17/2013 08:12 AM, gmt@malth.us wrote:
>>>> Why not simply fix the "not very well written configure scripts and
>>>> makefiles"instead? BTW I've never come across a single one of those.
>>>> Where are you getting yours?
>>> Can't answer this offhand (aware you didn't ask me :P) but, under the
>>> misguidance of PM's like Gentoo(portage) and rpm(build), when combined
>>> with poorly and/or belligerently written packaging scripts, this can
>>> happen incessantly.  But that mostly only comes up when building
>>> Frankencygwins. Sometimes you can fix it by forcing something like
>>> --prefix=///usr/local.
>
>> I'm trying to understand the reluctance towards "fixing the problem" and
> instead
>> the insistence on "putting a band aid on it". So in the above, why would
> you not
>> instead do --prefix=/usr/local?
>
> This  is indeed a band-aid in the truest sense of the metaphor.  It relies
> on the specificity of POSIX's reservation of "//" for platform purposes (and
> cygwin's correct implementation of same) -- unlike "//", anything matching
> the regex "^///[/]*$" is, indeed, equivalent to "/".  So, as if the POSIX
> "//" reservation wasn't an obscure enough fact, here is a way to /really/
> impress people at cocktail parties :)
>
> As to why not fix the upstreams committing these atrocities, it's the
> obvious reason -- occasionally one encounters a large body of dense,
> non-fixable-by-sed/perl, poorly commented "spaghetti" script-code that makes
> "clever," deep usage of the assumption that "//" == "/".  Being able to turn
> this feature off at one's option would enable them to rule out "//" as a
> problem when they suspect it might be, and have the additional benefit of
> not having to fix such code, in order to run it.

So it's a question of convenience vs correctness.  It seems the argument
offered is that it is convenient to allow incorrect scripts.  An alternate
argument could be made that it is equally convenient to continue having
Cygwin correctly interpret '//' as it has been.  In addition, since the UNC
interpretation of paths comes for free (it's a Windows feature), it
would be pretty inconvenient to make Cygwin work otherwise.

I don't think the convenience vs correctness argument is going to inspire
someone to action. ;-)

-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple