Re: File name syntax (WAS: RE: FW: Can not config sshd)

Re: File name syntax (WAS: RE: FW: Can not config sshd)

[Chris Faylor]

On Fri, May 26, 2000 at 04:50:19PM -0500, Parker, Ron wrote:
>> Bash's use of // should be fixed, IMO.  I did fix it once 
>> myself but I never
>> forwarded the changes to the maintainer.  My bad.
>
>As did I.  Would your preference be that I rework the patch for it and
>submit it to the bash maintainer?

Yes, please.  The bash maintainer is very responsible so I'm sure that
this will be included.  The cygwin bash maintainer is tbisp@uswest.net.
He would probably also be interested in incorporating this patch.

>Would a cygwin patch with server:share as an alternate form be welcome?

I dunno.  How about asking cygwin-developers?  I hate adding more checking
to the already slow path handling code but maybe everyone else will think
it is a nifty extension.

cgf


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: File name syntax (WAS: RE: FW: Can not config sshd)

[AJ Reins]

> Yes, please.  The bash maintainer is very responsible so I'm sure that
> this will be included.  The cygwin bash maintainer is tbisp@uswest.net.
> He would probably also be interested in incorporating this patch.

At the risk of repeating my self, I would be very interested in seeing
ANY and ALL Bash related patches. Please do not hesitate to either send
them directly to me at either of the below addresses, or send them to the list.

Also, please do not hesitate to mail me with ANY problems you might have.
I only ask that you use 2.04 as I had nothing to do with the production
of previous versions. Including the output of this command:

 set | grep -i bash

in your mail would be helpful.
-- 
AJ Reins - tbisp<AT>uswest.net -or- tbisp<AT>my-deja.com

If there is no time like the present,
 but we never have the time,
does this mean there is no present?

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: File name syntax (WAS: RE: FW: Can not config sshd)

[Chris Faylor]

On Tue, May 30, 2000 at 12:18:05PM -0500, Parker, Ron wrote:
>I would like to thank Chris for finding the reference in the Single UNIX
>Spec. where //path is implementation defined, Bob McGowan for his fine job
>of summarizing what started this whole thing, and everyone else for their
>input.
>
>Also I would like to apologize for setting off a match in a dry field with
>this topic.  I did not intend to fill everyone's mailboxes over the long
>holiday weekend in the US.  I did originally ask the question because I was
>concerned that there might be things I was not considering.
>
>I will not be working up the previously mentioned patch.  While it might
>solve some problems it is obvious that it would introduce more problems than
>it would cure.

No need to apologize.  I appreciate that this has now been clarified.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: File name syntax (WAS: RE: FW: Can not config sshd)

[Parker, Ron]

I would like to thank Chris for finding the reference in the Single UNIX
Spec. where //path is implementation defined, Bob McGowan for his fine job
of summarizing what started this whole thing, and everyone else for their
input.

Also I would like to apologize for setting off a match in a dry field with
this topic.  I did not intend to fill everyone's mailboxes over the long
holiday weekend in the US.  I did originally ask the question because I was
concerned that there might be things I was not considering.

I will not be working up the previously mentioned patch.  While it might
solve some problems it is obvious that it would introduce more problems than
it would cure.

Re: File name syntax (WAS: RE: FW: Can not config sshd)

[Andy Hare]

Chris,

    I too have suffered the problems with make failing when a // is used in
the path. However my problem was due to mounting another drive on the root
file system and using the file://e/ as the descriptor. The make process
would
fail. I have not tried using e: as the descriptor as I figured that e: was
not the Unix way to describe the disk. The make file was called with the
mount path but this was translated into the file://e name ether by make or
by
bash calling make. Either way it caused make a headache. Make would stop
retreating out of sub-directories and would eventually fail.

    I was actually trying to get the temporary build directory onto an empty
disk away from the root disk to give me more space. This was under b20.1 as
I haven't had the nerve to move to the latest net release yet. Waiting for
all the fuss to die down before I mess with a working system, I've made that
mistake before.

Andy Hare



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: File name syntax (WAS: RE: FW: Can not config sshd)

[Bernard Dautrevaux]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1668 bytes --]

> -----Original Message-----
> From: Larry Hall (RFK Partners, Inc) [ mailto:lhall@rfk.com ]
> Sent: Saturday, May 27, 2000 6:27 PM
> To: Parker, Ron; cygwin@sourceware.cygnus.com
> Subject: RE: File name syntax (WAS: RE: FW: Can not config sshd)
> 
> 
> 
> 
> At 05:22 PM 5/26/00, Parker, Ron wrote:
> > > Right.  The significance is for UNC paths which can be easily 
> > > access currently
> > > using "//<server name>/<share name>" in Cygwin now...
> >
> >Understood.  My intention was that server:share would be converted to
> >\\server\share before it reached the Windows file API's used 
> inside of
> >cygwin.  
> >
> >The entire idea was that many UNIX programs parse the colon 
> paths as network
> >paths already and this would bring cygwin a little more 
> inline with the UNIX
> >world.
> 
> 
> Actually, I should have said "//<server name>/<share 
> name>/<path>" to be 
> clear.
> 
> I guess as long as the NFS style syntax was supported by 
> Cygwin and was 
> supported in all places that the current UNC paths are 
> supported in Windows
> (i.e. *everywhere*), there shouldn't be any loss of 
> functionality with this
> change...
> 


Perhaps, but a great loss of compatibility... :-(

BTW, how did you put server:/tools/bin in you PATH?

Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: File name syntax (WAS: RE: FW: Can not config sshd)

[Bernard Dautrevaux]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2870 bytes --]

> -----Original Message-----
> From: Bob McGowan [ mailto:rmcgowan@veritas.com ]
> Sent: Saturday, May 27, 2000 12:28 AM
> To: Parker, Ron
> Cc: Chris Faylor; cygwin@sourceware.cygnus.com
> Subject: Re: File name syntax (WAS: RE: FW: Can not config sshd)
> 
> 
> 
> 
> If the decision stands to change bash, doesn't that imply a 
> need to fix
> the other shells too?
> 
> I think a single fix, in a common place for all applications, applied
> automatically (and without the application needing to know about it),
> would be preferred.  But as Chris points out, many users may 
> already be
> relying on the //name as a computer, leading to a lot of 
> editing to fix
> the problem.
> 
> Ron, you asked me about a free NFS client for windows.  At this time I
> don't know of one, but I'll see what I can find.  However, 
> this may not
> be needed.  With SAMBA available for UNIX systems, a translation of
> server:share to //server/share would transparently access the SAMBA
> server.  There are configuration issues to make this work 
> correctly but
> that is administration stuff.  I'd suggest not worrying about the NFS
> side.  What do you think?
> 
> "Parker, Ron" wrote:
> > 
> > > Bash's use of // should be fixed, IMO.  I did fix it once
> > > myself but I never
> > > forwarded the changes to the maintainer.  My bad.
> > 
> > As did I.  Would your preference be that I rework the patch 
> for it and
> > submit it to the bash maintainer?
> > 
> > Would a cygwin patch with server:share as an alternate form 
> be welcome?
> > 


My prime concern with this is that would need to also patch make to
understand that
	server:share/path: server2:share2/path2 
is a valid dependency rule (although I don't have the slightest idea of how
to do that unambiguously ;-|) ... or this would mean that we no more can use
cygwin for development...

I think I've understood that all this come from the fact that gnu tar accept
server:/path to access a tape drive on a remote system, using the "rmt"
daemon (and with nothing to do with NFS except that it use the same syntax
as the one use by "mount" to mount NFS file systems).

However there is no more places where we can use this syntax on UNIX: try to

	"ls server:/path"
and (at least with all UNIX systems I've tried this) you just get an error
:-)

So as cygwin is an UNIXonWIN32 layer, do NOT add a syntax that may broke
things and that is neither an UNIX syntax, nor a WIN32 syntax.

Just my 2 cents

		Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: File name syntax (WAS: RE: FW: Can not config sshd)

[Chris Faylor]

On Sun, May 28, 2000 at 08:14:15AM -0700, Earnie Boyd wrote:
>--- Chris Faylor <cgf@cygnus.com> wrote:
>-8<-
>> I have mixed feelings about this.  I routinely use //sys/share to access
>> remote
>> shares.  If cygwin had translated sys:share to //sys/share two or three years
>> ago then I would be using that mechanism instead.
>> 
>> Unfortunately, this use is embedded in various scripts on my machine.  I
>> would
>> be surprised if I was the only person who would be affected by this.
>
>Well, we've changed the way other things work without regard to what might
>break by doing so, e.g., the Windows path \ deal.  So, what's the sweat about
>this change, you just fix what breaks.

If you're referring to the use of backslash in path specs, the intent was to
help a lot of people who had a natural assumption that \foo\bar would refer
to c:\foo\bar if they were on the c: drive.  As you can see, I'm trying to
accomodate the Windows assumptions here.

Changing cygwin so that it ignored a leading // would be exactly the opposite
philosophy and it would basically just accomodate broken software rather
than natural user assumptions.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: File name syntax (WAS: RE: FW: Can not config sshd)

[Earnie Boyd]

--- Chris Faylor <cgf@cygnus.com> wrote:
-8<-
> I have mixed feelings about this.  I routinely use //sys/share to access
> remote
> shares.  If cygwin had translated sys:share to //sys/share two or three years
> ago then I would be using that mechanism instead.
> 
> Unfortunately, this use is embedded in various scripts on my machine.  I
> would
> be surprised if I was the only person who would be affected by this.
> 

Well, we've changed the way other things work without regard to what might
break by doing so, e.g., the Windows path \ deal.  So, what's the sweat about
this change, you just fix what breaks.

Cheers,

=====
---
   Earnie Boyd: < mailto:earnie_boyd@yahoo.com >
            __Cygwin: POSIX on Windows__
Cygwin Newbies: < http://www.freeyellow.com/members5/gw32/index.html >
           __Minimalist GNU for Windows__
  Mingw32 List: < http://www.egroups.com/group/mingw32/ >
    Mingw Home: < http://www.mingw.org/ >

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: File name syntax (WAS: RE: FW: Can not config sshd)

[Corinna Vinschen]

It's no general path problem and it's no general $HOME problem.
We only have that problem if an application is not enough
`defensive' in handling paths. IMHO, it's quite annoying that
some applications don't check the given path for trailing slash.
That's it, the missing check for trailing slash! Most of the time.

I think we should simply do that:
- Don't let the root dir be HOME. There's no reason to do so.
  Tell people that fact as often as they need it (FAQ?).
- Let's port applications so that they check the path for
  trailing slashes as far as it could result in a faulty
  UNC path (Yes, my openSSH port is affected as well!)

Corinna

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: File name syntax (WAS: RE: FW: Can not config sshd)

[David Bolen]

rmcgowan@veritas.com [rmcgowan@veritas.com] writes:

> The problem, as I understand it, was found when someone tried to do a make
and
> had errors, which were traced back to path names having two leading
slashes,
> which were then being interpreted as UNC paths.  But these were really
local
> path names, created because there was a variable with the value "/" which
was
> prepending to another value that began with a slash, resulting in names
with
> two leading slashes.  UNIX system handle this gracefully in some way,
making
> the "//" act like a single slash.

As I believe Chris mentioned in one of the earlier responses, an important 
point is that in general it's only safe to assume Unix systems will treat 
"//" as "/" if it occurs in the middle of a path specification, not at the 
front (which can be treated in a system-specific manner).  I don't believe
that 
all Unix systems handle such names similarly, nor automatically make them
act
like a single slash.

So at the Cygwin DLL level, I'd rather leave the behavior as is - a
convenient
system-defined manner of handling "//" to map to a useful Windows UNC
notation,
without requiring shell quoting.

-- David

/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l@fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: File name syntax (WAS: RE: FW: Can not config sshd)

[Robert McGowan]

> 
> On Fri, May 26, 2000 at 04:18:56PM -0700, Bob McGowan wrote:
> >Chris Faylor wrote:
> >> On Fri, May 26, 2000 at 03:27:36PM -0700, Bob McGowan wrote:
> >>>If the decision stands to change bash, doesn't that imply a need to fix
> >>>the other shells too?
> >>
> >>Have you seen a lot of traffic about other shells having this problem?
> >>I don't recall any.
> >
> >No.  But then, I also haven't seen a lot of traffic about people using
> >lots of //server stuff in scripts, either ;-)
> 
> I wouldn't expect people to report non-problems.  How many reports do
> you see of 'ls' working correctly?

Chris, I apologize for the less than clear and unhelpful comment I made above.

> >I was simply trying to point out a potential problem area, since any
> >application (shell or otherwise) working in a UNIX environment does not
> >need to worry itself about multiple slash characters anywhere in a path
> >name.  So, by implication, any application that uses paths, could
> >manifest this problem.  And since the application can be started from
> >either a command prompt or a shell, the further implication is that any
> >application handling paths would now need modification to be aware of
> >this special handling requirement.
> 
> As far as I can tell, we are trying to address a specific problem in
> bash by making a change to cygwin.  While you can speculate that this
> problem is rampant in many other programs, I do not believe that this
> is the case.
> 
> In fact, for instance, I believe that zsh collapses multiple occurrences
> of slashes so it actually does not have this problem.  I don't know about
> ash, but we can certainly fix this if so.  I doubt that it does introduce
> double backslashes by default, like bash does.
> 
> Zsh does have another problem in that it is not compliant with this:
> 
> http://www.opengroup.org/onlinepubs/007908799/xbd/glossary.html#tag_004_000_196

Thanks for the pointer.

---deleted material---

I've been reading some of todays responses to this subject line.  The topic
seems to have moved from concerns about multiple slashes at the beginning of
paths to a discussion on the merits of "NFS" path names vs. UNC.  Since my last
post on this, I've been thinking about the issues and trying to come up with
a clear analysis and understanding of the issues.  I'd like to rehash this, as
I think some of the opening details are relevant to the continuing discussion.

The problem, as I understand it, was found when someone tried to do a make and
had errors, which were traced back to path names having two leading slashes,
which were then being interpreted as UNC paths.  But these were really local
path names, created because there was a variable with the value "/" which was
prepending to another value that began with a slash, resulting in names with
two leading slashes.  UNIX system handle this gracefully in some way, making
the "//" act like a single slash.

One solution to this is to remove the special treatment of // in Cygwin and
make it more UNIX-like.  This has obvious repercussions for people who have
scripts that depend on the UNC interpretation.  And the proposed solution was
to use the "NFS" style pathing to replace the UNC, translating it to UNC when
passing it to Windows.  So "server:path" would convert to "\\server\path",
with the assumption that "path" would be a valide "share\path" when converted.
This was not intended to force people to have to mount the remote system in
order to use it.  Truth is, the "system:path" syntax is used by some non-NFS
commands like "rcp", so it may have been used for NFS because it was already
somewhat familiar to users.

This solution could be implemented either in the shell itself or in the cygwin
dll.  In either case, the problem for existing scripts persists, since bash is
most likely doing the script interpretation.

The original problem was traced to the default value assigned to the variable
HOME, which is "/".  A second solution mentioned was to have a sub-directory
name under "/", as the default value of HOME, which would eliminate the double
slash problem for this case. This solution does not change the UNC
interpretation, but does leave the system open to the production of the same
type of problem for other variables.  As a crude example:

	ParentDir=$(dirname $1) # where $1 == /name
	NewName=$ParentDir/myname # NewName == //myname

The bottom line is a choice between replacing UNC conventions with some other,
with all the related havoc for existing scripts, or fixing the base cause of
this one problem, leaving open the potential for this type of error happening
on some occasions in the future.

Bob McGowan

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: File name syntax (WAS: RE: FW: Can not config sshd)

[Chris Faylor]

On Sat, May 27, 2000 at 01:10:33PM -0400, Larry Hall (RFK Partners, Inc) wrote:
From my understanding of Ron's goals, I would say no.  He was
>proposing, AFAICT, that the UNC convention be replaced by NFS syntax
>for all paths.  Since NFS path syntax is really just an artifact of
>mount in the UNIX world, I wanted to be sure that he realized the
>implication that this would have.  AFAIK, tar is the only GNU utility
>that attempts to parse an NFS path itself.  I don't know of any other
>utility that does this.  I'm really luke-warm about the syntax change
>because I'm not really sure that NFS paths are more "UNIX- like" than
>UNC paths.  However, my main concern is if such a change is to happen
>that some mechanism be maintained so that network shares could be
>accessed though a simple path without requiring a mount to make it
>work.  Ron's response here was that the NFS syntax would fill that
>role, if I understood him correctly.
>
>Supporting NFS mount syntax in the mount table is a separate issue.  At
>this point, I don't have a problem with that idea although I also don't
>see an overwhelming need.
>
>Does this help clarify things for you?

I think I already understood the proposal but I don't understand why it
is being referred to as "NFS path syntax".  We aren't talking about,
AFAICT, NFS path syntax as much as we are referring to the syntax that
rcp, mount, and tar use for referring to remote files.

The goal here was to eliminate the special meaning of '//' since it is
"non-UNIX like" and to introduce the concept of remote file referral
using a "foo:/bar" syntax.  However, I think that having every program
automatically understand foo:/bar syntax is really not moving towards
UNIX compatibility.

On UNIX the programs which understand the colon syntax are specially
written to do so.  They don't rely on the OS to do translations.  So,
I don't think that it's a good idea to modify Cygwin to do this.

As far as slashes are concerned, however, maybe, adding a CYGWIN
environment variable would be ok, something on the order of
CYGWIN=collapse_all_slashes or something...

cgf


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: File name syntax (WAS: RE: FW: Can not config sshd)

[Chris Faylor]

On Sat, May 27, 2000 at 06:18:24PM -0500, AJ Reins wrote:
>Chris Faylor wrote:
>[SNIP]
>> Bash's use of // should be fixed, IMO.  I did fix it once myself but I never
>> forwarded the changes to the maintainer.  My bad.
>
>And I snarfed those changes and send them in during the beta test for
>Bash 2.04. I am unable to duplicate this problem, no matter how I try
>(i.e., setting HOME to "/" from command.com, then starting Bash, everything
>works fine. Unsetting HOME, then starting Bash however resulted in error
>message about it not being set.)
>
> Could you send any patches for Bash that you might have? I want to make
>sure that I have not messed up something. I was born paranoid, and there
>is no cure.

I don't have them anymore.  I believe that I submitted them to Cygnus before
I even started working there.

I'm wondering if this is a non-issue for bash 2.04.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: File name syntax (WAS: RE: FW: Can not config sshd)

[AJ Reins]

Chris Faylor wrote:
[SNIP]
> Bash's use of // should be fixed, IMO.  I did fix it once myself but I never
> forwarded the changes to the maintainer.  My bad.

And I snarfed those changes and send them in during the beta test for
Bash 2.04. I am unable to duplicate this problem, no matter how I try
(i.e., setting HOME to "/" from command.com, then starting Bash, everything
works fine. Unsetting HOME, then starting Bash however resulted in error
message about it not being set.)

Chris,
 Could you send any patches for Bash that you might have? I want to make
sure that I have not messed up something. I was born paranoid, and there
is no cure.

-- 
AJ Reins - tbisp<AT>uswest.net -or- tbisp<AT>my-deja.com

If there is no time like the present,
 but we never have the time,
does this mean there is no present?

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: File name syntax (WAS: RE: FW: Can not config sshd)

[Larry Hall (RFK Partners, Inc)]

At 12:44 PM 5/27/00, Chris Faylor wrote:


>On Sat, May 27, 2000 at 12:27:19PM -0400, Larry Hall (RFK Partners, Inc) wrote:
> >Date: Sat, 27 May 2000 12:27:19 -0400
> >To: "Parker, Ron" <rdparker@butlermfg.com>,
> >        "cygwin@sourceware.cygnus.com" <cygwin@hotpop.com>
> >From: "Larry Hall (RFK Partners, Inc)" <lhall@rfk.com>
> >Subject: RE: File name syntax (WAS: RE: FW: Can not config sshd)
> >In-Reply-To: <200005262126.RAA23411@acestes-fe0.ultra.net>
> >
> >
> >
> >At 05:22 PM 5/26/00, Parker, Ron wrote:
> >> > Right.  The significance is for UNC paths which can be easily 
> >> > access currently
> >> > using "//<server name>/<share name>" in Cygwin now...
> >>
> >>Understood.  My intention was that server:share would be converted to
> >>\\server\share before it reached the Windows file API's used inside of
> >>cygwin.  
> >>
> >>The entire idea was that many UNIX programs parse the colon paths as network
> >>paths already and this would bring cygwin a little more inline with the UNIX
> >>world.
>
>I missed this.  I don't think there are many UNIX *systems* out there which
>parse colons in pathnames.  Cygwin == a UNIX system.


BTW, this was Ron's comment not mine.  I also don't agree with it since I
don't consider NFS path syntax to be synonymous with UNIX path syntax.


> >Actually, I should have said "//<server name>/<share name>/<path>" to be 
> >clear.
> >
> >I guess as long as the NFS style syntax was supported by Cygwin and was 
> >supported in all places that the current UNC paths are supported in Windows
> >(i.e. *everywhere*), there shouldn't be any loss of functionality with this
> >change...
>
>I really don't understand what you are referring to.  When you mount a NFS
>directory you do use something of the form 'mount foo:/bar /baz' but the
>parsing of the colon is a function of mount not of the UNIX OS.  Programs
>like cp, cat, etc. do not treat colon separated filenames differently.
>
>Is this whole discussion really just about changin cygwin's mount command
>so that it accepts foo:/bar names?


 From my understanding of Ron's goals, I would say no.  He was proposing, 
AFAICT, that the UNC convention be replaced by NFS syntax for all paths.  
Since NFS path syntax is really just an artifact of mount in the UNIX world, 
I wanted to be sure that he realized the implication that this would have.
AFAIK, tar is the only GNU utility that attempts to parse an NFS path itself.
I don't know of any other utility that does this.  I'm really luke-warm about
the syntax change because I'm not really sure that NFS paths are more "UNIX-
like" than UNC paths.  However, my main concern is if such a change is to 
happen that some mechanism be maintained so that network shares could be 
accessed though a simple path without requiring a mount to make it work.  
Ron's response here was that the NFS syntax would fill that role, if I 
understood him correctly.  

Supporting NFS mount syntax in the mount table is a separate issue.  At this 
point, I don't have a problem with that idea although I also don't see an
overwhelming need.

Does this help clarify things for you?



Larry



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: File name syntax (WAS: RE: FW: Can not config sshd)

[Larry Hall (RFK Partners, Inc)]

At 07:49 PM 5/26/00, Chris Faylor wrote:
>On Fri, May 26, 2000 at 04:18:56PM -0700, Bob McGowan wrote:
> >A character string that is used to identify a file.  A pathname consists
> >of, at most, {PATH_MAX} bytes, including the terminating null byte.  It
> >has an optional beginning slash, followed by zero or more filenames
> >separated by slashes.  If the pathname refers to a directory, it may
> >also have one or more trailing slashes.  Multiple successive slashes are
> >considered to be the same as one slash.  A pathname that begins with two
> >successive slashes may be interpreted in an implementation-dependent
> >manner, although more than two leading slashes are treated as a single
> >slash.  The interpretation of the pathname is described in pathname
> >resolution .
>
>This issue has come up many times in the past.  Neither cygwin nor
>Windows NT is "non compliant" in the special handling of the double
>backslash at the start of a path.  There have been UNIX (or at least
>UNIX-like) OS's which interpret paths with a leading // specially.
>
>I normally am a big fan of fixing things in one place and I have been
>known to stand on my head, play the ukulele, and spin counter-clockwise
>in attempts to make cygwin behave more like UNIX.  I'm just not
>convinced that eliminating the use of a // is advisable.
>
>cgf



In an effort to walk the fine line between starting a round of "me too"
replies to this thread but still show support for the point being made 
without any hard statistics, I have to say I come down on Chris's side.
I think eliminating the use of UNC paths in favor of NFS style paths 
might be favorable moving forward but there will be problems with existing
scripts and so on (I have some of these too).  Also, I don't think there 
will be any real benefit if the result is more complex (and slower) path 
handling code.
   

I'm done!;-)


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX
                                        (508) 560-1285 - cell phone



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: File name syntax (WAS: RE: FW: Can not config sshd)

[Chris Faylor]

On Sat, May 27, 2000 at 12:27:19PM -0400, Larry Hall (RFK Partners, Inc) wrote:
>Date: Sat, 27 May 2000 12:27:19 -0400
>To: "Parker, Ron" <rdparker@butlermfg.com>,
>        "cygwin@sourceware.cygnus.com" <cygwin@hotpop.com>
>From: "Larry Hall (RFK Partners, Inc)" <lhall@rfk.com>
>Subject: RE: File name syntax (WAS: RE: FW: Can not config sshd)
>In-Reply-To: <200005262126.RAA23411@acestes-fe0.ultra.net>
>
>
>
>At 05:22 PM 5/26/00, Parker, Ron wrote:
>> > Right.  The significance is for UNC paths which can be easily 
>> > access currently
>> > using "//<server name>/<share name>" in Cygwin now...
>>
>>Understood.  My intention was that server:share would be converted to
>>\\server\share before it reached the Windows file API's used inside of
>>cygwin.  
>>
>>The entire idea was that many UNIX programs parse the colon paths as network
>>paths already and this would bring cygwin a little more inline with the UNIX
>>world.

I missed this.  I don't think there are many UNIX *systems* out there which
parse colons in pathnames.  Cygwin == a UNIX system.

>Actually, I should have said "//<server name>/<share name>/<path>" to be 
>clear.
>
>I guess as long as the NFS style syntax was supported by Cygwin and was 
>supported in all places that the current UNC paths are supported in Windows
>(i.e. *everywhere*), there shouldn't be any loss of functionality with this
>change...

I really don't understand what you are referring to.  When you mount a NFS
directory you do use something of the form 'mount foo:/bar /baz' but the
parsing of the colon is a function of mount not of the UNIX OS.  Programs
like cp, cat, etc. do not treat colon separated filenames differently.

Is this whole discussion really just about changin cygwin's mount command
so that it accepts foo:/bar names?

cgf


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: File name syntax (WAS: RE: FW: Can not config sshd)

[Larry Hall (RFK Partners, Inc)]

At 05:22 PM 5/26/00, Parker, Ron wrote:
> > Right.  The significance is for UNC paths which can be easily 
> > access currently
> > using "//<server name>/<share name>" in Cygwin now...
>
>Understood.  My intention was that server:share would be converted to
>\\server\share before it reached the Windows file API's used inside of
>cygwin.  
>
>The entire idea was that many UNIX programs parse the colon paths as network
>paths already and this would bring cygwin a little more inline with the UNIX
>world.


Actually, I should have said "//<server name>/<share name>/<path>" to be 
clear.

I guess as long as the NFS style syntax was supported by Cygwin and was 
supported in all places that the current UNC paths are supported in Windows
(i.e. *everywhere*), there shouldn't be any loss of functionality with this
change...


Larry



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: File name syntax (WAS: RE: FW: Can not config sshd)

[Chris Faylor]

On Fri, May 26, 2000 at 04:18:56PM -0700, Bob McGowan wrote:
>Chris Faylor wrote:
>> On Fri, May 26, 2000 at 03:27:36PM -0700, Bob McGowan wrote:
>>>If the decision stands to change bash, doesn't that imply a need to fix
>>>the other shells too?
>>
>>Have you seen a lot of traffic about other shells having this problem?
>>I don't recall any.
>
>No.  But then, I also haven't seen a lot of traffic about people using
>lots of //server stuff in scripts, either ;-)

I wouldn't expect people to report non-problems.  How many reports do
you see of 'ls' working correctly?

>I was simply trying to point out a potential problem area, since any
>application (shell or otherwise) working in a UNIX environment does not
>need to worry itself about multiple slash characters anywhere in a path
>name.  So, by implication, any application that uses paths, could
>manifest this problem.  And since the application can be started from
>either a command prompt or a shell, the further implication is that any
>application handling paths would now need modification to be aware of
>this special handling requirement.

As far as I can tell, we are trying to address a specific problem in
bash by making a change to cygwin.  While you can speculate that this
problem is rampant in many other programs, I do not believe that this
is the case.

In fact, for instance, I believe that zsh collapses multiple occurrences
of slashes so it actually does not have this problem.  I don't know about
ash, but we can certainly fix this if so.  I doubt that it does introduce
double backslashes by default, like bash does.

Zsh does have another problem in that it is not compliant with this:

http://www.opengroup.org/onlinepubs/007908799/xbd/glossary.html#tag_004_000_196

This URL comes from the "Single UNIX Specification" and it states:

>pathname
>
>A character string that is used to identify a file.  A pathname consists
>of, at most, {PATH_MAX} bytes, including the terminating null byte.  It
>has an optional beginning slash, followed by zero or more filenames
>separated by slashes.  If the pathname refers to a directory, it may
>also have one or more trailing slashes.  Multiple successive slashes are
>considered to be the same as one slash.  A pathname that begins with two
>successive slashes may be interpreted in an implementation-dependent
>manner, although more than two leading slashes are treated as a single
>slash.  The interpretation of the pathname is described in pathname
>resolution .

This issue has come up many times in the past.  Neither cygwin nor
Windows NT is "non compliant" in the special handling of the double
backslash at the start of a path.  There have been UNIX (or at least
UNIX-like) OS's which interpret paths with a leading // specially.

I normally am a big fan of fixing things in one place and I have been
known to stand on my head, play the ukulele, and spin counter-clockwise
in attempts to make cygwin behave more like UNIX.  I'm just not
convinced that eliminating the use of a // is advisable.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: File name syntax (WAS: RE: FW: Can not config sshd)

[Bob McGowan]

Chris Faylor wrote:
> 
> On Fri, May 26, 2000 at 03:27:36PM -0700, Bob McGowan wrote:
> >If the decision stands to change bash, doesn't that imply a need to fix
> >the other shells too?
> 
> Have you seen a lot of traffic about other shells having this problem?
> I don't recall any.

No.  But then, I also haven't seen a lot of traffic about people using
lots of //server stuff in scripts, either ;-)  

I was simply trying to point out a potential problem area, since any
application (shell or otherwise) working in a UNIX environment does not
need to worry itself about multiple slash characters anywhere in a path
name.  So, by implication, any application that uses paths, could
manifest this problem.  And since the application can be started from
either a command prompt or a shell, the further implication is that any
application handling paths would now need modification to be aware of
this special handling requirement.

-- 
Bob McGowan
Staff Software Quality Engineer
VERITAS Software
rmcgowan@veritas.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: File name syntax (WAS: RE: FW: Can not config sshd)

[Chris Faylor]

On Fri, May 26, 2000 at 03:27:36PM -0700, Bob McGowan wrote:
>If the decision stands to change bash, doesn't that imply a need to fix
>the other shells too?

Have you seen a lot of traffic about other shells having this problem?
I don't recall any.

cgf


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: File name syntax (WAS: RE: FW: Can not config sshd)

[Bob McGowan]

If the decision stands to change bash, doesn't that imply a need to fix
the other shells too?

I think a single fix, in a common place for all applications, applied
automatically (and without the application needing to know about it),
would be preferred.  But as Chris points out, many users may already be
relying on the //name as a computer, leading to a lot of editing to fix
the problem.

Ron, you asked me about a free NFS client for windows.  At this time I
don't know of one, but I'll see what I can find.  However, this may not
be needed.  With SAMBA available for UNIX systems, a translation of
server:share to //server/share would transparently access the SAMBA
server.  There are configuration issues to make this work correctly but
that is administration stuff.  I'd suggest not worrying about the NFS
side.  What do you think?

"Parker, Ron" wrote:
> 
> > Bash's use of // should be fixed, IMO.  I did fix it once
> > myself but I never
> > forwarded the changes to the maintainer.  My bad.
> 
> As did I.  Would your preference be that I rework the patch for it and
> submit it to the bash maintainer?
> 
> Would a cygwin patch with server:share as an alternate form be welcome?
> 
>   ------------------------------------------------------------------------
>    Part 1.2Type: Plain Text (text/plain)

-- 
Bob McGowan
Staff Software Quality Engineer
VERITAS Software
rmcgowan@veritas.com


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: File name syntax (WAS: RE: FW: Can not config sshd)

[Parker, Ron]

> Bash's use of // should be fixed, IMO.  I did fix it once 
> myself but I never
> forwarded the changes to the maintainer.  My bad.

As did I.  Would your preference be that I rework the patch for it and
submit it to the bash maintainer?

Would a cygwin patch with server:share as an alternate form be welcome?

Re: File name syntax (WAS: RE: FW: Can not config sshd)

[Chris Faylor]

On Fri, May 26, 2000 at 05:13:34PM -0500, Larry Hall (RFK Partners, Inc) wrote:
>At 04:07 PM 5/26/00, Parker, Ron wrote:
>> > >In other words, "///myfile" would translate to "/myfile" and
>> > >"machine:dir/file" or "machine:/dir/file" would map to the 
>> > Windows path
>> > >\\machine\dir\file.
>>
>> > I'm assuming by "Make multiple introductory slashes", you're 
>> > excluding the
>> > case of "//"?
>>
>>That wasn't exactly what I was thinking.  I used three for emphasis, but
>>meant that one or more initial slashes would be treated as a single initial
>>slash.
>>
>>It is the Friday before a long weekend and I might be completely brain-dead,
>>but I don't remember a special significance to '//' in UNIX.
>
>Right.  The significance is for UNC paths which can be easily access currently
>using "//<server name>/<share name>" in Cygwin now...

I have mixed feelings about this.  I routinely use //sys/share to access remote
shares.  If cygwin had translated sys:share to //sys/share two or three years
ago then I would be using that mechanism instead.

Unfortunately, this use is embedded in various scripts on my machine.  I would
be surprised if I was the only person who would be affected by this.

Bash's use of // should be fixed, IMO.  I did fix it once myself but I never
forwarded the changes to the maintainer.  My bad.

cgf


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: File name syntax (WAS: RE: FW: Can not config sshd)

[Parker, Ron]

> Right.  The significance is for UNC paths which can be easily 
> access currently
> using "//<server name>/<share name>" in Cygwin now...

Understood.  My intention was that server:share would be converted to
\\server\share before it reached the Windows file API's used inside of
cygwin.  

The entire idea was that many UNIX programs parse the colon paths as network
paths already and this would bring cygwin a little more inline with the UNIX
world.

RE: File name syntax (WAS: RE: FW: Can not config sshd)

[Parker, Ron]

> The network part is something I cannot comment on in detail though it
> looks OK.  I would wonder what would happen if I had an NFS client
> installed, with some UNIX NFS server file system mounted, would the
> format UNXISERVER:nfs_mount be correctly handled?

I am not sure at this point, but I am willing to look at it if I can get my
hands on a free NFS client for Windows.

RE: File name syntax (WAS: RE: FW: Can not config sshd)

[Larry Hall (RFK Partners, Inc)]

At 04:07 PM 5/26/00, Parker, Ron wrote:
> > >In other words, "///myfile" would translate to "/myfile" and
> > >"machine:dir/file" or "machine:/dir/file" would map to the 
> > Windows path
> > >\\machine\dir\file.
>
> > I'm assuming by "Make multiple introductory slashes", you're 
> > excluding the
> > case of "//"?
>
>That wasn't exactly what I was thinking.  I used three for emphasis, but
>meant that one or more initial slashes would be treated as a single initial
>slash.
>
>It is the Friday before a long weekend and I might be completely brain-dead,
>but I don't remember a special significance to '//' in UNIX.


Right.  The significance is for UNC paths which can be easily access currently
using "//<server name>/<share name>" in Cygwin now...


Larry



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: File name syntax (WAS: RE: FW: Can not config sshd)

[Parker, Ron]

> >In other words, "///myfile" would translate to "/myfile" and
> >"machine:dir/file" or "machine:/dir/file" would map to the 
> Windows path
> >\\machine\dir\file.

> I'm assuming by "Make multiple introductory slashes", you're 
> excluding the
> case of "//"?

That wasn't exactly what I was thinking.  I used three for emphasis, but
meant that one or more initial slashes would be treated as a single initial
slash.

It is the Friday before a long weekend and I might be completely brain-dead,
but I don't remember a special significance to '//' in UNIX.

Re: File name syntax (WAS: RE: FW: Can not config sshd)

[Larry Hall (RFK Partners, Inc)]

At 12:22 PM 5/26/00, Bob McGowan wrote:
> > 
> > Which makes me wonder would a patch to cygwin be welcome that did the
> > following?
> > 
> > * Make multiple introductory slashes on a path behave as a single
> > introductory slash
> > * Make paths that begin with name: and contain no backslashes behave as a
> > network path
> > 
> > In other words, "///myfile" would translate to "/myfile" and
> > "machine:dir/file" or "machine:/dir/file" would map to the Windows path
> > \\machine\dir\file.
> > 
>
>I would endorse this, since it would make the operation of Cygwin more
>'unix like'.  All unix systems I'm familiar with (mostly SVR3 and SVR4
>derived) treat a '//' the same as '/./' so a path that comes up looking
>like //usr/src
>is handled correctly.  I would speculate that this was done so the root
>user's home directory '/' would work correctly with absolute path names
>generated elsewhere.
>
>Currently Cygwin treats multiple slashes in a path (abc//xyz) in this
>way, anyway, so doing so for leading slashes would also make the
>operation consistent.


The problem with this is it would disallow the use of UNC paths.  To avoid  
this, care would be needed to avoid collapsing the initial "//" to "/".
However, my guess is that excluding the initial "//" works against the goal
that Ron was originally envisioning (i.e. the elimination of subtle errors 
resulting from erroneous occurrences of "//", in addition to "///", "////",
etc).  Seems to me like this goal may well be addressed by simply having bash 
handle an undefined HOME variable more appropriately, like perhaps what 
Earnie suggested.

I see no obvious problem with the introduction of the NFS path scheme.  Its a
bit "non-standard" for UNIX outside of NFS circles but then again, so is UNC.



Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX
                                        (508) 560-1285 - cell phone



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: File name syntax (WAS: RE: FW: Can not config sshd)

[Bob McGowan]

> 
> Which makes me wonder would a patch to cygwin be welcome that did the
> following?
> 
> * Make multiple introductory slashes on a path behave as a single
> introductory slash
> * Make paths that begin with name: and contain no backslashes behave as a
> network path
> 
> In other words, "///myfile" would translate to "/myfile" and
> "machine:dir/file" or "machine:/dir/file" would map to the Windows path
> \\machine\dir\file.
> 

I would endorse this, since it would make the operation of Cygwin more
'unix like'.  All unix systems I'm familiar with (mostly SVR3 and SVR4
derived) treat a '//' the same as '/./' so a path that comes up looking
like //usr/src
is handled correctly.  I would speculate that this was done so the root
user's home directory '/' would work correctly with absolute path names
generated elsewhere.

Currently Cygwin treats multiple slashes in a path (abc//xyz) in this
way, anyway, so doing so for leading slashes would also make the
operation consistent.

The network part is something I cannot comment on in detail though it
looks OK.  I would wonder what would happen if I had an NFS client
installed, with some UNIX NFS server file system mounted, would the
format UNXISERVER:nfs_mount be correctly handled?

-- 
Bob McGowan
Staff Software Quality Engineer
VERITAS Software
rmcgowan@veritas.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: File name syntax (WAS: RE: FW: Can not config sshd)

[Earnie Boyd]

--- "Parker, Ron" <rdparker@butlermfg.com> wrote:
> > No, bash defaults HOME to / and then that get's prepended to 
> > the path name
> > after it resolves the tilde character ~ sor ~/myfile bcomes 
> > //myfile.  Now the
> > problem with //myfile is that // is translated to \\ and 
> > \\myfile as a server
> > doesn't exist.  The time it takes to eventually time out is 
> > directly related to
> > the number of domains your associated with * the timeout 
> > period * the number of
> > retries.  This is the reason we now have /cygdrive instead of 
> > using // to
> > denote an unmounted device/directory.
> 
> Which makes me wonder would a patch to cygwin be welcome that did the
> following?
> 
> * Make multiple introductory slashes on a path behave as a single
> introductory slash
> * Make paths that begin with name: and contain no backslashes behave as a
> network path
> 
> In other words, "///myfile" would translate to "/myfile" and
> "machine:dir/file" or "machine:/dir/file" would map to the Windows path
> \\machine\dir\file.
> 

Grand idea.  I like both of these.  I actually was thinking of bringing this up
on the developers list but you beat me to it.

There is/might be a problem in that your change isn't backward compatible and
although you as a developer have had /cygdrive syntax for sometime.  AFAICR
b20.1 had it or have I just forgotten what it had.

IMO, for the time being bash and sh should be changed to default to /home and
have setup create a /home directory.

Cheers,

=====
---
   Earnie Boyd: < mailto:earnie_boyd@yahoo.com >
            __Cygwin: POSIX on Windows__
Cygwin Newbies: < http://www.freeyellow.com/members5/gw32/index.html >
           __Minimalist GNU for Windows__
  Mingw32 List: < http://www.egroups.com/group/mingw32/ >
    Mingw Home: < http://www.mingw.org/ >

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: File name syntax (WAS: RE: FW: Can not config sshd)

[Larry Hall (RFK Partners, Inc)]

At 12:00 PM 5/26/00, Parker, Ron wrote:
>Which makes me wonder would a patch to cygwin be welcome that did the
>following?
>
>* Make multiple introductory slashes on a path behave as a single
>introductory slash
>* Make paths that begin with name: and contain no backslashes behave as a
>network path
>
>In other words, "///myfile" would translate to "/myfile" and
>"machine:dir/file" or "machine:/dir/file" would map to the Windows path
>\\machine\dir\file.



I'm assuming by "Make multiple introductory slashes", you're excluding the
case of "//"?



Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX
                                        (508) 560-1285 - cell phone



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

File name syntax (WAS: RE: FW: Can not config sshd)

[Parker, Ron]

> No, bash defaults HOME to / and then that get's prepended to 
> the path name
> after it resolves the tilde character ~ sor ~/myfile bcomes 
> //myfile.  Now the
> problem with //myfile is that // is translated to \\ and 
> \\myfile as a server
> doesn't exist.  The time it takes to eventually time out is 
> directly related to
> the number of domains your associated with * the timeout 
> period * the number of
> retries.  This is the reason we now have /cygdrive instead of 
> using // to
> denote an unmounted device/directory.

Which makes me wonder would a patch to cygwin be welcome that did the
following?

* Make multiple introductory slashes on a path behave as a single
introductory slash
* Make paths that begin with name: and contain no backslashes behave as a
network path

In other words, "///myfile" would translate to "/myfile" and
"machine:dir/file" or "machine:/dir/file" would map to the Windows path
\\machine\dir\file.