X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:reply-to:mime-version:to
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=a24GHlAuA2SoXBkI
	lnWXQY95Gnxqm8gQV69a58sqLCy7p8i0ZpfqjUptFIXA5KWerhxb4hGqAUU9bDA3
	76uqQi9gJMDoFz6XYD8KNF69k1NWI+mDzvvPfuH2a18vwmXSu1XGXyMDdGU//UeV
	MqdG5cXZmFb/ezbRajo20l/Tywk=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:reply-to:mime-version:to
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=5tckEYzBx2gjd/rRKVs4Se
	hqzQM=; b=tGdJRlbQjwhoC1pjeWY52nZECfLp7brLguBg8XumvRJGgVog41WYL0
	7av/p4SYyzoBcwyTBzuqB3PkJyViJ9YvnKEu9np+hGrhKo4DrSHJqckgej6kJBWn
	QrQBHIkZQQskjtk+JD7sUJf5R3jNKk6Y+wxFXpAwli/g3wHGId1Ps=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
X-Spam-SWARE-Status:	No, score=2.0 required=5.0 tests=AWL,BAYES_00,BOTNET,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_YE autolearn=no version=3.3.1
Message-id:	<51BF534E.2030200@cygwin.com>
Date:	Mon, 17 Jun 2013 14:19:58 -0400
From:	"Larry Hall (Cygwin)" <reply-to-list-only-lh AT cygwin DOT com>
Reply-to:	cygwin AT cygwin DOT com
User-Agent:	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-version:	1.0
To:	cygwin AT cygwin DOT com
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$@malth.us> <kpnfp7$urd$1 AT ger DOT gmane DOT org> <03b201ce6b83$c5b62720$51227560$@malth.us>
In-reply-to:	<03b201ce6b83$c5b62720$51227560$@malth.us>

On 6/17/2013 1:54 PM, gmt AT malth DOT us wrote:
> On Mon, 17 Jun 2013, at 10:07, Andrew DeFaria thusly quipped:
>> On 06/17/2013 08:12 AM, gmt AT malth DOT 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

- Raw text -