From mboxrd@z Thu Jan 1 00:00:00 1970 From: rmcgowan@veritas.com (Robert McGowan) To: cygwin@sourceware.cygnus.com Cc: rmcgowan@veritas.com Subject: Re: File name syntax (WAS: RE: FW: Can not config sshd) Date: Sun, 28 May 2000 00:05:00 -0000 Message-id: References: <20000526194914.B24370@cygnus.com> X-SW-Source: 2000-05/msg01028.html > > 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