Greg.

Thanks a lot for the info. I had '//' mixed up with machine 
name//:<pathname> used by the mount command.

regards
-kamal







"Greg A. Woods" <woods@weird.com>
09/08/2003 08:00 PM
Please respond to tech-kern
 
        To:     Kamal R Prasad/India/IBM@IBMIN
        cc:     David Laight <david@l8s.co.uk>, tech-kern@NetBSD.org
        Subject:        Re: Pathnames with trailing /

 

[ On Monday, September 8, 2003 at 12:45:12 (+0530), Kamal R Prasad wrote: 
]
> Subject: Re: Pathnames with trailing /
>
> How can a pathname have more than one trailing slash? Either you have a 
> trailing slash to imply you are referring to a directory *only* or none 
to 
> imply that it can be a filename [or a pathname].

Actually with the traditional and proper UNIX System way of doing things
the slash character in a pathname is a separator token only and it
doesn't matter how many there are at any place in a pathname, and even
putting one or more at the end of the pathname doesn't imply anything
special.  This is well documented right back into the Sixth Edition
source code, as per the Lions' commentary on that code.

This "invention" of the IEEE POSIX folks comes directly from a
relatively late change unique in the unix-like systems world, as far as
I know, only to BSD as distributed by CSRG, which of course has been
maintained in the three subsequent direct derivatives.  (*BSD heads
can't say POSIX never did anything for them!)

The original Unix view of pathname separators is much more elegant.
It's also much more intuitive, once you understand the true meaning of
the slash character.  After all, if one really wanted to specify an
existing pathname as a directory then one would be quite explicit about
it and properly append the "/." and not depend on the non-portable
behaviour of some particular kernel to do this for them.

Note also that all the whining about problems of trailing slashes
introduced by shells that do filename completion in a certain way is
pure bunk.  These problems only occur in *BSD systems because of the
poor decision to treat trailing slashes as something more than just
extraneous separator tokens.  On traditional systems those trailing
slashes are simply ignored by the kernel and thus such problems cannot
ever occur.  Trailing slashes should not imply that a pathname is
supposed to be directory.  They should be stripped and ignored as any
trailing whitespace would be by any shell tokenizer, or ignored as
additional trailing NUL characters are ignored by both applications and
the kernel.  The worst possible thing to do is to pretend that the
filename "." has been appended to the pathname and yet that's exactly
the choice that was made for *BSD.

I don't know what we're supposed to do now that POSIX has embedded this
stupid behaviour in their standard, except perhaps ignore it completely.
It seems to me that despite the POSIX blessing on this *BSD-unique
feature that other systems will continue to ignore POSIX (and *BSD) and
that no portable application will ever be able to rely on it one way or
another.  In these kinds of situations I think the only reasonable
approach is to undo the mistake in the standard and try to encourage
those fewer unique systems (such as NetBSD) to revert to the traditional
Unix behavour.  That's the only way I can ever see compatability ever
being reached on this matter.

-- 
                 Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack 
<woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird 
<woods@weird.com>