UNC and POSIX paths

UNC and POSIX paths

[Fedin Pavel]

 Hello!

 I decided to pay attention to one more problem. Lots of not very well
written configure scripts and makefiles like to access things like
'//usr/bin'. Under Cygwin this causes problem because Cygwin treats '//' in
Windows-style as access to network shares.
 What if we change this ? We could have a mount entry, something like '/unc'
(or /smb, /net, whatever) and access it like '/smb/computername/sharename'.
I think this would improve POSIX compatibility a lot.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia




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

Re: UNC and POSIX paths

[Andrew DeFaria]

On 06/17/2013 06:36 AM, Fedin Pavel wrote:
>   Hello!
>
>   I decided to pay attention to one more problem. Lots of not very well
> written configure scripts and makefiles like to access things like
> '//usr/bin'. Under Cygwin this causes problem because Cygwin treats '//' in
> Windows-style as access to network shares.
>   What if we change this ? We could have a mount entry, something like '/unc'
> (or /smb, /net, whatever) and access it like '/smb/computername/sharename'.
> I think this would improve POSIX compatibility a lot.
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?
-- 
Andrew DeFaria <http://defaria.com>
Very funny Scotty - now beam down my clothes.


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

Re: UNC and POSIX paths

[Christopher Faylor]

On Mon, Jun 17, 2013 at 05:36:42PM +0400, Fedin Pavel wrote:
> Hello!
>
> I decided to pay attention to one more problem. Lots of not very well
>written configure scripts and makefiles like to access things like
>'//usr/bin'. Under Cygwin this causes problem because Cygwin treats '//' in
>Windows-style as access to network shares.
> What if we change this ? We could have a mount entry, something like '/unc'
>(or /smb, /net, whatever) and access it like '/smb/computername/sharename'.
>I think this would improve POSIX compatibility a lot.

To rephrase what you're asking: "How about if we change Cygwin's
path-handling to deviate from 15 years of established behavior?"

Sorry, not going to happen.  We're within our rights to treat //
differently and, although it doesn't give us complete Linux
compatibility, this is one case where the utility outweighs the
pedantry.

That said, I guess we *could* add something like the above and only use
it when it was specifically mounted but that would be a fair amount of
work.

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

Re: UNC and POSIX paths

[Dan Kegel]

On Mon, Jun 17, 2013 at 6:36 AM, Fedin Pavel wrote:
>  I decided to pay attention to one more problem. Lots of not very well
> written configure scripts and makefiles like to access things like
> '//usr/bin'. Under Cygwin this causes problem because Cygwin treats '//' in
> Windows-style as access to network shares.
>  What if we change this ? We could have a mount entry, something like '/unc'
> (or /smb, /net, whatever) and access it like '/smb/computername/sharename'.
> I think this would improve POSIX compatibility a lot.

It'd be interesting to find out how many such scripts there are.
Have you tried looking for them, e.g. by hooking open()
( http://stackoverflow.com/questions/880263/how-can-i-detect-file-accesses-in-linux
)
and logging them while doing something big (like rebuilding a linux distro,
or building all your company's linux software)?
- Dan

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

RE: UNC and POSIX paths

[gmt]

On Mon, 17 Jun 2013, at 06:57, Andrew DeFaria thusly quipped:

> On 06/17/2013 06:36 AM, Fedin Pavel wrote:
>>   Hello!
>>   
>>   I decided to pay attention to one more problem. Lots of not very
>> well written configure scripts and makefiles like to access things
>> like '//usr/bin'. Under Cygwin this causes problem because Cygwin
>> treats '//' in Windows-style as access to network shares.
>>   What if we change this ? We could have a mount entry, something like
'/unc'
>> (or /smb, /net, whatever) and access it like
'/smb/computername/sharename'.
>> I think this would improve POSIX compatibility a lot.
> 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.

A CYGWIN env flag to disable UNC paths, or graft them somewhere other than
//, or an fstab-hack--basically anything allowing one to turn this feature
off--would be a moderate blessing for a small number (greater than or equal
to one) of people, but SHTDI, and this is endlessly proposed and
insta-shot-down.

At least one "merit-based" argument does recommend against implementing this
-- a great many configure scripts test for whether // == /, which means
packages could break if packagers happened to build while using the proposed
anti-feature-feature (the inevitable response being, "shouldn't those
packages just fix their broken configure scripts"? :P)

-gmt



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

Re: UNC and POSIX paths

[Corinna Vinschen]

On Jun 17 17:36, Fedin Pavel wrote:
>  Hello!
> 
>  I decided to pay attention to one more problem. Lots of not very well
> written configure scripts and makefiles like to access things like
> '//usr/bin'. Under Cygwin this causes problem because Cygwin treats '//' in
> Windows-style as access to network shares.
>  What if we change this ? We could have a mount entry, something like '/unc'
> (or /smb, /net, whatever) and access it like '/smb/computername/sharename'.
> I think this would improve POSIX compatibility a lot.

Maybe there has been said enough in this thread already, but I have
to add this:  Cygwin's behaviour *is* POSIX compatible.  Consider
this excerpt from SUSv4 Base specifications, section 4.12 "Pathname
Resolution" (1):

  A pathname consisting of a single <slash> shall resolve to the root
  directory of the process. [...] If a pathname begins with two
  successive <slash> characters, the first component following the
  leading <slash> characters may be interpreted in an
  implementation-defined manner, although more than two leading <slash>
  characters shall be treated as a single <slash> character.


Corinna

(1) http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html


-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

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

Re: UNC and POSIX paths

[Andrew DeFaria]

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?
> A CYGWIN env flag to disable UNC paths, or graft them somewhere other than
> //, or an fstab-hack--basically anything allowing one to turn this feature
> off--would be a moderate blessing for a small number (greater than or equal
> to one) of people, but SHTDI, and this is endlessly proposed and
> insta-shot-down.
>
> At least one "merit-based" argument does recommend against implementing this
> -- a great many configure scripts test for whether // == /, which means
> packages could break if packagers happened to build while using the proposed
> anti-feature-feature (the inevitable response being, "shouldn't those
> packages just fix their broken configure scripts"? :P)
Yes, indeed. See above.
-- 
Andrew DeFaria <http://defaria.com>
If a mute swears does his mother wash his hands with soap?


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

Re: UNC and POSIX paths

[Achim Gratz]

Andrew DeFaria writes:
> 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?

Because some scripts try to use

$(DESTDIR)/$(PREFIX)

rather than

$(DESTDIR)$(PREFIX)

or otherwise insist on adding a slash somewhere in the expansion of
directory paths without checking whether they are "" or "/".  While it'd
be preferable that these expansions be fixed, simply prepending a few
more slashes usually works when the system follows POSIX rules since
only "//" is special.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada


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

RE: UNC and POSIX paths

[gmt]

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.

-gmt



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

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

Re: UNC and POSIX paths

[Andrew DeFaria]

On 06/17/2013 10:35 AM, Achim Gratz wrote:
> Andrew DeFaria writes:
>> 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?
> Because some scripts try to use
>
> $(DESTDIR)/$(PREFIX)
>
> rather than
>
> $(DESTDIR)$(PREFIX)
>
> or otherwise insist on adding a slash somewhere in the expansion of
> directory paths without checking whether they are "" or "/".  While it'd
> be preferable that these expansions be fixed, simply prepending a few
> more slashes usually works when the system follows POSIX rules since
> only "//" is special.
I'm confused. Let me ask a different way - why not fix such scripts 
instead? That's all I'm asking.
-- 
Andrew DeFaria <http://defaria.com>
Copywight 1994 Elmer Fudd. All wights wesewved.


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

Re: UNC and POSIX paths

[Andrew DeFaria]

On 06/17/2013 10:54 AM, gmt@malth.us wrote:
> 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. 
> -gmt 
If upstream code is broken it's broken. You can 1) fix it and submit it 
as a patch or 2) don't fix it and find a better solution.

Stripping off additional '/''s is not that hard a problem to solve - 
even in spaghetti code.
-- 
Andrew DeFaria <http://defaria.com>
I just got skylights put in my place. The people who live above me are 
furious!


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

Re: UNC and POSIX paths

[Dan Kegel]

Andrew DeFaria wrote:
> I'm confused. Let me ask a different way - why not fix such scripts instead?
> That's all I'm asking.

He's probably daunted by the thought.

If he really wants to change the world here, he should
consider writing a tool that scanned for such problems,
and lobbying to get it included in some broadly used suite of checks
like lintian.
- Dan

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

Re: UNC and POSIX paths

[Andrew DeFaria]

On 06/17/2013 12:01 PM, Dan Kegel wrote:
> Andrew DeFaria wrote:
>> I'm confused. Let me ask a different way - why not fix such scripts instead?
>> That's all I'm asking.
> He's probably daunted by the thought.
Doesn't really address the question.

OK, I'm out of here...
-- 
Andrew DeFaria <http://defaria.com>
Always try to be modest. And be damn proud of it!


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

Re: UNC and POSIX paths

[Dan Kegel]

Andrew DeFaria wrote:
>>> I'm confused. Let me ask a different way - why not fix such scripts
>>> instead?
>>
>> He's probably daunted by the thought.
>>[snipped description of how to approach this huge task]
>
> Doesn't really address the question.

Armed with the tool I outlined, one could have a realistic
chance at fixing all such scripts in finite time.
- Dan

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

RE: UNC and POSIX paths

[gmt]

On Mon, 17 Jun 2013, at 11:19, Larry Hall (Cygwin) thusly quipped:
> 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. ;-)

On Mon, 17 Jun 2013, at 12:01, Dan Kegel thusly quipped:
> Andrew DeFaria wrote:
>> I'm confused. Let me ask a different way - why not fix such scripts
instead?
>> That's all I'm asking.
> 
> He's probably daunted by the thought.
> 
> If he really wants to change the world here, he should consider writing a
tool
> that scanned for such problems, and lobbying to get it included in some
broadly
> used suite of checks like lintian.
> - Dan

Geez, tough ml.  If you are referring to me, you've misunderstood.

This was a rhetorical exercise, not an advocacy campaign :)  At no point
have I advocated not fixing broken scripts, or changing the world in any
way.  And I am undaunted by thoughts.  Mostly, I couldn't resist giving a
literal answer to Andrew's (maybe-not-so-literally-intended) question of
"why not fix it?" (nevertheless, I did fix it, already).

Plus, I reasoned that, as somebody who could have benefited from OP's
proposal in the past, I was in a good position to play devil's advocate (I
expected the other side of the argument would be adequately presented by
everyone else but me).

BTW, along the same lines, I stated previously it would break
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=m4/double-sl
ash-root.m4.  Turns out I was wrong, the m4 has a hard-coded list of
platforms.  So, I have to say, I can't think of one technical or merit-based
reason this shouldn't be done, aside from the fact that it's annoying to
hear it endlessly brought up on the mailing list (a problem which an
implementation would, in fact, solve, not exacerbate).

-gmt



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

Re: UNC and POSIX paths

[Andrew DeFaria]

On 06/17/2013 07:18 PM, gmt@malth.us wrote:
> Mostly, I couldn't resist giving a literal answer to Andrew's 
> (maybe-not-so-literally-intended) question of "why not fix it?" 
> (nevertheless, I did fix it, already). 
I see, and I rest my case...
-- 
Andrew DeFaria <http://defaria.com>
A Clean House Is A Sign Of A Misspent Life


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

Re: UNC and POSIX paths

[Christopher Faylor]

On Mon, Jun 17, 2013 at 07:18:12PM -0700, gmt@malth.us wrote:
>BTW, along the same lines, I stated previously it would break
>http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=m4/double-sl
>ash-root.m4.  Turns out I was wrong, the m4 has a hard-coded list of
>platforms.  So, I have to say, I can't think of one technical or merit-based
>reason this shouldn't be done, aside from the fact that it's annoying to
>hear it endlessly brought up on the mailing list (a problem which an
>implementation would, in fact, solve, not exacerbate).

I can't quite follow the logic here but if you're saying that if we no
longer treated // as /, people who want to use //usr/local/bin would not
complain, you're right.  That doesn't mean that a whole new class of
complainer would not show up, however.

I can say with absolute certainty that there is one person who would
complain.

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

RE: UNC and POSIX paths

[gmt]

On Mon, 17 Jun 2013, at 21:42, Christopher Faylor thusly quipped:

> On Mon, Jun 17, 2013 at 07:18:12PM -0700, gmt@malth.us wrote:
>> BTW, along the same lines, I stated previously it would break
>> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=m4/doub
>> le-sl ash-root.m4.  Turns out I was wrong, the m4 has a hard-coded list
>> of platforms.  So, I have to say, I can't think of one technical or
>> merit-based reason this shouldn't be done, aside from the fact that
>> it's annoying to hear it endlessly brought up on the mailing list (a
>> problem which an implementation would, in fact, solve, not exacerbate).
> 
> I can't quite follow the logic here but if you're saying that if we no
longer
> treated // as /, people who want to use //usr/local/bin would not
complain,
> you're right.  That doesn't mean that a whole new class of complainer
would not
> show up, however.
> 
> I can say with absolute certainty that there is one person who would
complain.

I was imagining a less intrusive hypothetical approach.

For example, perhaps a CYGWIN=nounc flag that would simply turn the feature
off, or a way to deactivate in fstab -- in short, anything reversible, and,
by default, preserving the existing behavior.  Prune-grafting "//" to "/smb"
might have been a good idea had it been done at cygwin's inception, but I
think it's probably too late now.

Although I hate to continue casting myself in this "advocate" role -- I
really have very little stake in this -- otherwise you would have patches
for this, rather than 1000 words.

-gmt



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

RE: UNC and POSIX paths

[Fedin Pavel]

 Hello!

> Because some scripts try to use
> 
> $(DESTDIR)/$(PREFIX)
> 
> rather than
> 
> $(DESTDIR)$(PREFIX)

 Yes, exactly, this is what i have got.
 I start to have these problems when i try to do non-standard things like
cross-compiling Linux kernel and some 3rd party modules. :)
 Ability to run 'make install_modules' requires /sbin/depmod. With hardcoded
/sbin path. So, i have to cross-compile module-init-tools with '--prefix=/'.
This is the first place where i get '//'. Well, perhaps i'm lame and
'--prefix=' is the correct thing, not what i write. However i just followed
the tradition here
 Next, module-init-tools relies on either 'docbook2man' or 'docbook-to-man'.
I guess both packages are considered obsolete by Cygwin, we have
'docbook2x-man' instead. So, i have to build one of those two packages.
$(DESTDIR)/$(PREFIX) is found in the first one.
 Well, perhaps irrelevant because it fails to build with new awk (or
something like that, already don't remember). So i have found (ancient)
docbook-to-man and built it. Works.

 Also i remember getting this little problem somewhere else in the past.
Already don't remember...

 Now my last arguments...
 First. Actually, we may consider this as kind of interoperability problem.
Technically it's possible to fix this at either side. However, let's say we
have three packages suffering from this problem. So, it's possible to do
either three fixes (for packages), or a single fix (for Cygwin). A single
fix is less time-consuming. Especially taking into account that a half of us
uses Cygwin at work, where we have other tasks to do.
 Second, if we take a look at real-world POSIX systems (Linux, BSD, whatever
else), they don't use '//' for network paths. Instead they use mountable
filesystems. And Cygwin's goal is to fully implement UNIX-compatible
environment, isn't it ? So, consequently, having a mount point would me more
compatible with other real-world systems.
 Third, package's author can say: 'nobody else has this problem, so it's
Cygwin's bug, not mine, i won't fix'. Or he can simply blindly hate Windows.
My another topic (cross-compiling Linux kerne) contains an example of such
an attitude.
 And, i agree, '//' is shorter to type than '/unc/'. :) And perhaps someone
already relies on '//' in his scripts for his installation.

 To sum things up, this was just an opinion. I didn't want to start a war.
:)

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia



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

Re: UNC and POSIX paths

[Václav Zeman]

[-- Attachment #1: Type: text/plain, Size: 2683 bytes --]

On 06/18/2013 08:20 AM, Fedin Pavel wrote:
>  Hello!
> 
>> Because some scripts try to use
>>
>> $(DESTDIR)/$(PREFIX)
>>
>> rather than
>>
>> $(DESTDIR)$(PREFIX)
> 
>  Yes, exactly, this is what i have got.
>  I start to have these problems when i try to do non-standard things like
> cross-compiling Linux kernel and some 3rd party modules. :)
>  Ability to run 'make install_modules' requires /sbin/depmod. With hardcoded
> /sbin path. So, i have to cross-compile module-init-tools with '--prefix=/'.
> This is the first place where i get '//'. Well, perhaps i'm lame and
> '--prefix=' is the correct thing, not what i write. However i just followed
> the tradition here
>  Next, module-init-tools relies on either 'docbook2man' or 'docbook-to-man'.
> I guess both packages are considered obsolete by Cygwin, we have
> 'docbook2x-man' instead. So, i have to build one of those two packages.
> $(DESTDIR)/$(PREFIX) is found in the first one.
>  Well, perhaps irrelevant because it fails to build with new awk (or
> something like that, already don't remember). So i have found (ancient)
> docbook-to-man and built it. Works.
Does replacing "/" with "/." help or does it not help? I cannot test
this right now.


> 
>  Also i remember getting this little problem somewhere else in the past.
> Already don't remember...
> 
>  Now my last arguments...
>  First. Actually, we may consider this as kind of interoperability problem.
> Technically it's possible to fix this at either side. However, let's say we
> have three packages suffering from this problem. So, it's possible to do
> either three fixes (for packages), or a single fix (for Cygwin). A single
> fix is less time-consuming. Especially taking into account that a half of us
> uses Cygwin at work, where we have other tasks to do.
>  Second, if we take a look at real-world POSIX systems (Linux, BSD, whatever
> else), they don't use '//' for network paths. Instead they use mountable
> filesystems. And Cygwin's goal is to fully implement UNIX-compatible
> environment, isn't it ? So, consequently, having a mount point would me more
> compatible with other real-world systems.
>  Third, package's author can say: 'nobody else has this problem, so it's
> Cygwin's bug, not mine, i won't fix'. Or he can simply blindly hate Windows.
> My another topic (cross-compiling Linux kerne) contains an example of such
> an attitude.
>  And, i agree, '//' is shorter to type than '/unc/'. :) And perhaps someone
> already relies on '//' in his scripts for his installation.
> 
>  To sum things up, this was just an opinion. I didn't want to start a war.
> :)

-- 
VZ




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

RE: UNC and POSIX paths

[Fedin Pavel]

 Hello!

> Does replacing "/" with "/." help or does it not help? I cannot test
> this right now.

 Yes, it does, this is how i did it. So - yes, it is also a matter of
convenience, and time needed to find this workaround.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia



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

Re: UNC and POSIX paths

[Corinna Vinschen]

On Jun 17 22:47, gmt@malth.us wrote:
> On Mon, 17 Jun 2013, at 21:42, Christopher Faylor thusly quipped:
> 
> > On Mon, Jun 17, 2013 at 07:18:12PM -0700, gmt@malth.us wrote:
> >> BTW, along the same lines, I stated previously it would break
> >> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=m4/doub
> >> le-sl ash-root.m4.  Turns out I was wrong, the m4 has a hard-coded list
> >> of platforms.  So, I have to say, I can't think of one technical or
> >> merit-based reason this shouldn't be done, aside from the fact that
> >> it's annoying to hear it endlessly brought up on the mailing list (a
> >> problem which an implementation would, in fact, solve, not exacerbate).
> > 
> > I can't quite follow the logic here but if you're saying that if we no
> longer
> > treated // as /, people who want to use //usr/local/bin would not
> complain,
> > you're right.  That doesn't mean that a whole new class of complainer
> would not
> > show up, however.
> > 
> > I can say with absolute certainty that there is one person who would
> complain.
> 
> I was imagining a less intrusive hypothetical approach.
> 
> For example, perhaps a CYGWIN=nounc flag that would simply turn the feature
> off, or a way to deactivate in fstab -- in short, anything reversible, and,
> by default, preserving the existing behavior.  Prune-grafting "//" to "/smb"
> might have been a good idea had it been done at cygwin's inception, but I
> think it's probably too late now.

A mount table approach along the lines of the cygdrive prefix handling
might not be such a bad thing, after all.  Something along these lines

  none /mnt cygdrive binary,posix=0,user 0 0
  none /unc uncdrive binary,posix=0 0 0

This would also fix the somewhat special feature that unc paths get the
same default flag treatment as cygdrive paths.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

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

Re: UNC and POSIX paths

[Christopher Faylor]

On Tue, Jun 18, 2013 at 12:26:32PM +0200, Corinna Vinschen wrote:
>On Jun 17 22:47, gmt@malth.us wrote:
>> On Mon, 17 Jun 2013, at 21:42, Christopher Faylor thusly quipped:
>> 
>> > On Mon, Jun 17, 2013 at 07:18:12PM -0700, gmt@malth.us wrote:
>> >> BTW, along the same lines, I stated previously it would break
>> >> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=m4/doub
>> >> le-sl ash-root.m4.  Turns out I was wrong, the m4 has a hard-coded list
>> >> of platforms.  So, I have to say, I can't think of one technical or
>> >> merit-based reason this shouldn't be done, aside from the fact that
>> >> it's annoying to hear it endlessly brought up on the mailing list (a
>> >> problem which an implementation would, in fact, solve, not exacerbate).
>> > 
>> > I can't quite follow the logic here but if you're saying that if we no
>> longer
>> > treated // as /, people who want to use //usr/local/bin would not
>> complain,
>> > you're right.  That doesn't mean that a whole new class of complainer
>> would not
>> > show up, however.
>> > 
>> > I can say with absolute certainty that there is one person who would
>> complain.
>> 
>> I was imagining a less intrusive hypothetical approach.
>> 
>> For example, perhaps a CYGWIN=nounc flag that would simply turn the feature
>> off, or a way to deactivate in fstab -- in short, anything reversible, and,
>> by default, preserving the existing behavior.  Prune-grafting "//" to "/smb"
>> might have been a good idea had it been done at cygwin's inception, but I
>> think it's probably too late now.
>
>A mount table approach along the lines of the cygdrive prefix handling
>might not be such a bad thing, after all.  Something along these lines
>
>  none /mnt cygdrive binary,posix=0,user 0 0
>  none /unc uncdrive binary,posix=0 0 0
>
>This would also fix the somewhat special feature that unc paths get the
>same default flag treatment as cygdrive paths.

That's what I was proposing earlier in the thread.  It's a SHTDI
proposal, of course.

cgf

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

Re: UNC and POSIX paths

[Christopher Faylor]

On Tue, Jun 18, 2013 at 10:30:09AM -0400, Christopher Faylor wrote:
>On Tue, Jun 18, 2013 at 12:26:32PM +0200, Corinna Vinschen wrote:
>>On Jun 17 22:47, gmt@malth.us wrote:
>>> On Mon, 17 Jun 2013, at 21:42, Christopher Faylor thusly quipped:
>>> 
>>> > On Mon, Jun 17, 2013 at 07:18:12PM -0700, gmt@malth.us wrote:
>>> >> BTW, along the same lines, I stated previously it would break
>>> >> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=m4/doub
>>> >> le-sl ash-root.m4.  Turns out I was wrong, the m4 has a hard-coded list
>>> >> of platforms.  So, I have to say, I can't think of one technical or
>>> >> merit-based reason this shouldn't be done, aside from the fact that
>>> >> it's annoying to hear it endlessly brought up on the mailing list (a
>>> >> problem which an implementation would, in fact, solve, not exacerbate).
>>> > 
>>> > I can't quite follow the logic here but if you're saying that if we no
>>> longer
>>> > treated // as /, people who want to use //usr/local/bin would not
>>> complain,
>>> > you're right.  That doesn't mean that a whole new class of complainer
>>> would not
>>> > show up, however.
>>> > 
>>> > I can say with absolute certainty that there is one person who would
>>> complain.
>>> 
>>> I was imagining a less intrusive hypothetical approach.
>>> 
>>> For example, perhaps a CYGWIN=nounc flag that would simply turn the feature
>>> off, or a way to deactivate in fstab -- in short, anything reversible, and,
>>> by default, preserving the existing behavior.  Prune-grafting "//" to "/smb"
>>> might have been a good idea had it been done at cygwin's inception, but I
>>> think it's probably too late now.
>>
>>A mount table approach along the lines of the cygdrive prefix handling
>>might not be such a bad thing, after all.  Something along these lines
>>
>>  none /mnt cygdrive binary,posix=0,user 0 0
>>  none /unc uncdrive binary,posix=0 0 0
>>
>>This would also fix the somewhat special feature that unc paths get the
>>same default flag treatment as cygdrive paths.
>
>That's what I was proposing earlier in the thread.  It's a SHTDI
>proposal, of course.

And, it nontrivially complicates path handling since we'd have to make
decisions about whether to honor // or not.

If we do consider this, I think we should take a step back and think
about revamping path handling to allow hooks for things like /dev,
/proc, /cygdrive rather than having to special case them.

cgf

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

Re: UNC and POSIX paths

[Earnie Boyd]

On Tue, Jun 18, 2013 at 10:36 AM, Christopher Faylor wrote:
>
> And, it nontrivially complicates path handling since we'd have to make
> decisions about whether to honor // or not.
>

I'd suggest using /// for UNC, dropping exactly one / if FILEPATH[0]
and FILEPATH[1] is equal to /.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

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

Re: UNC and POSIX paths

[Corinna Vinschen]

On Jun 18 11:05, Earnie Boyd wrote:
> On Tue, Jun 18, 2013 at 10:36 AM, Christopher Faylor wrote:
> >
> > And, it nontrivially complicates path handling since we'd have to make
> > decisions about whether to honor // or not.
> >
> 
> I'd suggest using /// for UNC, dropping exactly one / if FILEPATH[0]
> and FILEPATH[1] is equal to /.

That's not POSIX compatible.  See the URL I posted earlier in this thread.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

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

Re: UNC and POSIX paths

[Andrey Repin]

Greetings, Christopher Faylor!

> And, it nontrivially complicates path handling since we'd have to make
> decisions about whether to honor // or not.

That's an easy decision: "//" should remain as Cygwin/POSIX equivalent of
"\\" AKA UNC path access.
If anyone want to argument against it with broken scripting examples, ...
I would question their sanity.

> If we do consider this, I think we should take a step back and think
> about revamping path handling to allow hooks for things like /dev,
> /proc, /cygdrive rather than having to special case them.

SHTDI, as you said... But it'd be interesting advancement in /etc/fstab
evolution.


--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 19.06.2013, <02:29>

Sorry for my terrible english...


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

RE: UNC and POSIX paths

[Fedin Pavel]

 Hello!

> > If we do consider this, I think we should take a step back and think
> > about revamping path handling to allow hooks for things like /dev,
> > /proc, /cygdrive rather than having to special case them.
> 
> SHTDI, as you said... But it'd be interesting advancement in /etc/fstab
> evolution.

 You mean implement complete VFS ? Would be extremely interesting. Would be
very cool to be able to build FUSE backends. This way we could access
various filesystems, not supported by Windows. Or, if we are BSDish enough,
we could take BSD filesystem modules...

 P.S. I know about Dokan project (http://dokan-dev.net/en/about/), but at
least on my machine it didn't work, simply crashed. Additionally, i'm not
sure if i can take source code of FUSE filesystem and build it for Dokan.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia



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