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

[rmcgowan at veritas dot com (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