paths like //usr/local

paths like //usr/local

[Sven Köhler]

hi,

a path like //usr/local is treated as an UNC path.
this might leads to problems when an application is using //usr/local as 
a normal "unix"-path.

i don't know how to overcome the problem, but one might think of a path 
like /unc/computer/share instead of using the path //computer/share

what was the idea behind the current behaviour?





--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: paths like //usr/local

[cygwin]

On Tue, Oct 15, 2002 at 08:09:50PM +0200, Sven K?hler wrote:
>hi,
>
>a path like //usr/local is treated as an UNC path.
>this might leads to problems when an application is using //usr/local as 
>a normal "unix"-path.
>
>i don't know how to overcome the problem, but one might think of a path 
>like /unc/computer/share instead of using the path //computer/share
>
>what was the idea behind the current behaviour?

Do you think that Microsoft employees read this mailing list?  I'm sure
that there are one or two but I doubt that they could speak definitively
about why Microsoft chose this behavior.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: paths like //usr/local

[Sven Köhler]

>>a path like //usr/local is treated as an UNC path.
>>this might leads to problems when an application is using //usr/local as 
>>a normal "unix"-path.
>>
>>i don't know how to overcome the problem, but one might think of a path 
>>like /unc/computer/share instead of using the path //computer/share
>>
>>what was the idea behind the current behaviour?
> 
> Do you think that Microsoft employees read this mailing list?  I'm sure
> that there are one or two but I doubt that they could speak definitively
> about why Microsoft chose this behavior.

cygwin translates paths like /usr/local to c:\cygwin\usr\local and 
manages mount-points etc...
cygwin opffers a complete "virtual filesystem"

the cygwin-developers chose, to NOT convert //usr/local to 
c:\cygwin\usr\local

i would like to know why.




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: paths like //usr/local

[Christopher Faylor]

On Tue, Oct 15, 2002 at 09:09:27PM +0200, Sven K?hler wrote:
>>>a path like //usr/local is treated as an UNC path.
>>>this might leads to problems when an application is using //usr/local as 
>>>a normal "unix"-path.
>>>
>>>i don't know how to overcome the problem, but one might think of a path 
>>>like /unc/computer/share instead of using the path //computer/share
>>>
>>>what was the idea behind the current behaviour?
>>
>>Do you think that Microsoft employees read this mailing list?  I'm sure
>>that there are one or two but I doubt that they could speak definitively
>>about why Microsoft chose this behavior.
>
>cygwin translates paths like /usr/local to c:\cygwin\usr\local and 
>manages mount-points etc...
>cygwin opffers a complete "virtual filesystem"
>
>the cygwin-developers chose, to NOT convert //usr/local to 
>c:\cygwin\usr\local
>
>i would like to know why.

Think of it another way:

cygwin allows the user to specify paths like: c:\foo\bar and c:/foo/bar.
Similarly, it allows //foo/bar and \\foo\bar .

If that doesn't satisfy you then you can go back to the "Because we're mean"
argument.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: paths like //usr/local

[Igor Pechtchanski]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1846 bytes --]

On Tue, 15 Oct 2002, [ISO-8859-1] Sven Köhler wrote:

> >>a path like //usr/local is treated as an UNC path.
> >>this might leads to problems when an application is using //usr/local as
> >>a normal "unix"-path.
> >>
> >>i don't know how to overcome the problem, but one might think of a path
> >>like /unc/computer/share instead of using the path //computer/share
> >>
> >>what was the idea behind the current behaviour?
> >
> > Do you think that Microsoft employees read this mailing list?  I'm sure
> > that there are one or two but I doubt that they could speak definitively
> > about why Microsoft chose this behavior.
>
> cygwin translates paths like /usr/local to c:\cygwin\usr\local and
> manages mount-points etc...
> cygwin opffers a complete "virtual filesystem"
>
> the cygwin-developers chose, to NOT convert //usr/local to
> c:\cygwin\usr\local
>
> i would like to know why.

Sven,
Basically your complaint is inconsistent behavior of multiple contiguous
slashes depending on where they occur in the path (i.e., the initial two
slashes won't be collapsed, but elsewhere in the path they will be).
Perhaps something like a unc_prefix is in order, similar to the cygdrive
prefix?
"Patches gratefully accepted" (C).  Oops, sorry, I guess it's "Donations
gleefully accepted" now... :-D
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Water molecules expand as they grow warmer" (C) Popular Science, Oct'02, p.51


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: paths like //usr/local

[Sven Köhler]

> "Patches gratefully accepted" (C).  Oops, sorry, I guess it's "Donations
> gleefully accepted" now... :-D

what do you mean with that?



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: paths like //usr/local

[Christopher Faylor]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 2087 bytes --]

On Tue, Oct 15, 2002 at 03:51:19PM -0400, Igor Pechtchanski wrote:
>On Tue, 15 Oct 2002, [ISO-8859-1] Sven Köhler wrote:
>
>> >>a path like //usr/local is treated as an UNC path.
>> >>this might leads to problems when an application is using //usr/local as
>> >>a normal "unix"-path.
>> >>
>> >>i don't know how to overcome the problem, but one might think of a path
>> >>like /unc/computer/share instead of using the path //computer/share
>> >>
>> >>what was the idea behind the current behaviour?
>> >
>> > Do you think that Microsoft employees read this mailing list?  I'm sure
>> > that there are one or two but I doubt that they could speak definitively
>> > about why Microsoft chose this behavior.
>>
>> cygwin translates paths like /usr/local to c:\cygwin\usr\local and
>> manages mount-points etc...
>> cygwin opffers a complete "virtual filesystem"
>>
>> the cygwin-developers chose, to NOT convert //usr/local to
>> c:\cygwin\usr\local
>>
>> i would like to know why.
>
>Sven,
>Basically your complaint is inconsistent behavior of multiple contiguous
>slashes depending on where they occur in the path (i.e., the initial two
>slashes won't be collapsed, but elsewhere in the path they will be).
>Perhaps something like a unc_prefix is in order, similar to the cygdrive
>prefix?
>"Patches gratefully accepted" (C).  Oops, sorry, I guess it's "Donations
>gleefully accepted" now... :-D

Not in this case.  There is no way that I'm going to change long-standing
behavior in cygwin.

To quote from the Single Unix Specification v3:

"A pathname consisting of a single slash shall resolve to the root
directory of the process.  A null pathname shall not be successfully
resolved.  A pathname that begins with two successive slashes may be
interpreted in an implementation-defined manner, although more than two
leading slashes shall be treated as a single slash."

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: paths like //usr/local

[Jan Nieuwenhuizen]

Christopher Faylor <cygwin@cygwin.com> writes:

> cygwin allows the user to specify paths like: c:\foo\bar and c:/foo/bar.
> Similarly, it allows //foo/bar and \\foo\bar .

> If that doesn't satisfy you then you can go back to the "Because we're mean"
> argument.

I've been hurt by this too, and it makes me think.  It would be even
more satisfactory if some configurable list of 'hosts' would map to
//localhost/.  Hosts with names such as \\bin, \\etc, \\tmp,
\\usr or \\var come to mind.

Now if such a thing could be implemented without some horrible kludge,
would that be nice?

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: paths like //usr/local

[Sven Köhler]

> Perhaps something like a unc_prefix is in order, similar to the cygdrive
> prefix?

the sollution that paths like //comp/share are interpreted like an 
UNC-path is just not compatible with an application might expect from a 
unix-environment.
the 2 slashes should be collapsed and nothing else.

> "Patches gratefully accepted" (C).  Oops, sorry, I guess it's "Donations
> gleefully accepted" now... :-D

which unc-prefix would that be?

i would prefer an "automount-like" feature as i already suggested:
/unc-mount-point-path/computer/share
where
/unc-mount-point-path/computer/
might be a virtual folder with all shares avaiable and
/unc-mount-point-path/
might be a virtual folder with all known computers

just an idea.




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: paths like //usr/local

[Shankar Unni]

On 10/15/2002 1:05 PM, Sven Köhler wrote:

> the sollution that paths like //comp/share are interpreted like an 
> UNC-path is just not compatible with an application might expect from a 
> unix-environment.

Don't be silly - there are Unix-y environments where "//" doesn't work 
the way you think they "should" work. The "//" notation has been used in 
many shared-filesystem implementations as a hostname or sharename prefix.

Please, leave things as they are. The POSIX standard specifically sets 
aside the leading "//" prefix for just such situations. Just because 
you've never worked in an environment like this before doesn't mean that 
the rest of us should be handicapped to accommodate you..
--
Shankar.




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: paths like //usr/local

[Shankar Unni]

On 10/15/2002 1:05 PM, Sven Köhler wrote:

> the sollution that paths like //comp/share are interpreted like an 
> UNC-path is just not compatible with an application might expect from a 
> unix-environment.

And there are other things too. Perhaps cygwin should ban "\" file 
separators in paths? After all, most Unix-en don't accept "\" as a file 
component separator, and "\" is a legal character in filenames on Unix-en..

Cygwin is not Linux.
--
Shankar.




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: paths like //usr/local

[egor duda]

Hi!

Wednesday, 16 October, 2002 Sven Köhler skoehler@upb.de wrote:

SK> the sollution that paths like //comp/share are interpreted like an
SK> UNC-path is just not compatible with an application might expect from a 
SK> unix-environment.

Then those applications are making false assumptions. Expecting two
leading slashes to be interpreted like single one is non-portable and
therefore is wrong. Chris has already cited appropriate words from
standard.

Just fix the application. Ain't that simple?

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: paths like //usr/local

[Sven Köhler]

> To quote from the Single Unix Specification v3:
> 
> "A pathname consisting of a single slash shall resolve to the root
> directory of the process.  A null pathname shall not be successfully
> resolved.  A pathname that begins with two successive slashes may be
> interpreted in an implementation-defined manner, although more than two
> leading slashes shall be treated as a single slash."

damn - who wrote that spec?

i might think of autoconf's configure-script when using things like 
--with-package=/ which might lead ./configure to look for //include/test.h

but than it's configure's fault, not cygwin's
(i know that i could say --with-package=/.  :-) )




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: paths like //usr/local

[Sven Köhler]

> To quote from the Single Unix Specification v3:
> 
> "A pathname consisting of a single slash shall resolve to the root
> directory of the process.  A null pathname shall not be successfully
> resolved.  A pathname that begins with two successive slashes may be
> interpreted in an implementation-defined manner, although more than two
> leading slashes shall be treated as a single slash."

damn - who wrote that spec?

i might think of autoconf's configure-script when using things like 
--with-package=/ which might lead ./configure to look for //include/test.h

but than it's configure's fault, not cygwin's
(i know that i could say --with-package=/.  :-) )


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: paths like //usr/local

[Scott Prive]

FYI: I actually *had* hostnames like "var", "tmp" and so on at one time... :-)


Cygwin maps UNIX/POSIX behavior on top of NT, but NT was designed to be compatible with DOS's *broken* conventions, so NT is half-broken.

Any kind of parsing for mounts like you suggest would probably incur a performance hit, generate limitations, and cause breakage everywhere. 

The escaping can be annoying but it's livable IMO. I suggest not to use //, but to use the "proper" path convention -- and escape accordingly. This is more keystrokes and more to remember, but it seems bugfree and 100% consistent. I shudder at the thought of `rm -rf /path` going to an "interpreted" mount point.

Example: 

Desired path: \\server\share

Bash: \\\\server\\share

Perl - going THROUGH bash, using system():
\\\\\\\\server\\\\share 

Slightly off topic, but standard Bash *does* support hostname completion. You have to configure it -- see standard BASH2 documentation online. I have no idea how well it works with Cygwin and with UNC pathing, but it works on UNIX with automount and ssh.

If nothing, it could be extended by someone for UNC.

-Scott 

> -----Original Message-----
> From: Jan Nieuwenhuizen [mailto:janneke@gnu.org]
> Sent: Tuesday, October 15, 2002 4:01 PM
> To: cygwin@cygwin.com
> Subject: Re: paths like //usr/local
> 
> 
> Christopher Faylor <cygwin@cygwin.com> writes:
> 
> > cygwin allows the user to specify paths like: c:\foo\bar 
> and c:/foo/bar.
> > Similarly, it allows //foo/bar and \\foo\bar .
> 
> > If that doesn't satisfy you then you can go back to the 
> "Because we're mean"
> > argument.
> 
> I've been hurt by this too, and it makes me think.  It would be even
> more satisfactory if some configurable list of 'hosts' would map to
> //localhost/.  Hosts with names such as \\bin, \\etc, \\tmp,
> \\usr or \\var come to mind.
> 
> Now if such a thing could be implemented without some horrible kludge,
> would that be nice?
> 
> Jan.
> 
> -- 
> Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The 
> music typesetter
> http://www.xs4all.nl/~jantien       | http://www.lilypond.org
> 
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
> 
> 

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/