This is the mail archive of the
mailing list for the Cygwin project.
Re: UNC and POSIX paths
- From: "Larry Hall (Cygwin)" <reply-to-list-only-lh at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Mon, 17 Jun 2013 14:19:58 -0400
- Subject: Re: UNC and POSIX paths
- References: <003501ce6b5f$b41f2c10$1c5d8430$%fedin at samsung dot com> <kpn4kk$p88$1 at ger dot gmane dot org> <036c01ce6b6d$0ada5090$208ef1b0$ at malth dot us> <kpnfp7$urd$1 at ger dot gmane dot org> <03b201ce6b83$c5b62720$51227560$ at malth dot us>
- Reply-to: cygwin at cygwin dot com
On 6/17/2013 1:54 PM, email@example.com wrote:
On Mon, 17 Jun 2013, at 10:07, Andrew DeFaria thusly quipped:
On 06/17/2013 08:12 AM, firstname.lastname@example.org 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
I'm trying to understand the reluctance towards "fixing the problem" and
the insistence on "putting a band aid on it". So in the above, why would
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. ;-)
> 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
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple