On Thursday 2013-08-08 21:15, Linda Walsh wrote:

the Shell has no recognized syntax for NFS.

But since '//' is reserved in POSIX to not be collapsed, it would be nice to be able to use it like on cygwin, where I can access SMBFS drives in bash as simply as: ls //servername/share

Linux is not Cygwin. The UNC paths only work in Cygwin because it has to ultimately pass them to Windows routines which will interpret them accordingly. Which is also why you can issue `ls C:\\` in cygwin, too. (And it will warn you about classic paths, as well.) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt wrote:

Linux is not Cygwin.

Cygwin is being POSIX compliant in preserving the '//' and passing it to the OS. I was wondering if Linux could provide callout support for // (if it doesn't already).. so it could be vectored to autofs which could automount whatever you wanted CIFS/NFS...etc.... Does linux remove // from the paths before passing them to drivers? That would likely be a case of posix incompatibility (std. disclaimer -- I generally detest posix in its later forms (post 2002) where it goes beyond it's initial charter to be "descriptive and not prescriptive".) But the below dates to old posix, so I'm not going to complain...;-) 3.269 Path Prefix The part of a pathname up to, but not including, the last component and any trailing <slash> characters, unless the pathname consists entirely of <slash> characters, in which case the path prefix is '/' for a pathname containing either a single <slash> or three or more <slash> characters, and '//' for the pathname //. ---- Note, my inital post saying that 3 or more slashes = 1 slash was correct. But 2 '//' are special in POSIX -- even BASH won't remove them. I.e. if you cd /// --you get / if you cd //, you get // as your pwd: Ishtar:/> pwd / Ishtar:/> cd // Ishtar://> pwd // -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt wrote:

On Thursday 2013-08-08 23:37, Linda Walsh wrote:

...

Does linux remove // from the paths before passing them to drivers?

Yes, see fs/namei.c:link_path_walk:

static int link_path_walk(const char *name, struct nameidata *nd) { struct path next; int err;

while (*name=='/') name++;

But that is not a problem, because drivers only have to answer to the VFS, not to the user.

But VFS, unlike 'users' has it's own bug subcategory under "filesystems" in the lkml bugzilla... ;-) `Sides's wouldn't it be better behavior to have it be POSIX compatible and preserve the '//' and and hand off the path to drivers (user-mode or kernel) un-mangled?

(I suppose you mean > filesystems)

"Filesystems" are database formats on media. They need drivers to interact with something -- like a linux kernel. To have an object participate in the the "the kernel", it needs something that knows the "rules of the road" for the specific OS. Similarly, a hired "driver" is often for foreign objects (file systems, hardware, "foreigners") when the 'foreign' body doesn't know the "rules of the kernel" for each OS (or Country) it interacts with. It's a sign of similar base points when the foci of the argument are on semantics. ;-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Joerg Schilling wrote:

Linda Walsh wrote:

...

Jan Engelhardt wrote:

...

On Thursday 2013-08-08 23:37, Linda Walsh wrote:

...

Does linux remove // from the paths before passing them to drivers? Yes, see fs/namei.c:link_path_walk:

static int link_path_walk(const char *name, struct nameidata *nd) { struct path next; int err;

while (*name=='/') name++;

But that is not a problem, because drivers only have to answer to the VFS, not to the user.

---

But VFS, unlike 'users' has it's own bug subcategory under "filesystems" in the lkml bugzilla... ;-)

`Sides's wouldn't it be better behavior to have it be POSIX compatible and preserve the '//' and and hand off the path to drivers (user-mode or kernel) un-mangled?

As mentioned several time before: POSIX does not require to preserve //. POSIX just permits to preserve // in order to allow to implement the Integrated Solutions global filesystem semantics.

This is a quote from POSIX: Linda Walsh wrote:

3.269 Path Prefix

The part of a pathname up to, but not including, the last component and any trailing <slash> characters, unless the pathname consists entirely of <slash> characters, in which case the path prefix is '/' for a pathname containing either a single <slash> or three or more <slash> characters, and '//' for the pathname //.

---- If you are going to return the path prefix before the filename, you must preserve '//', or you are not following the above direct quote from POSIX 2008. It may have *permitted* it before in the older standard, I would _well_ believe, as I said, POSIX, post~2002 has gone beyone their charter to be descriptive and not prescriptive. As the standard stands now, retaining '//' is *prescriptive*. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Linda Walsh wrote:

...

POSIX does not require this but it permits the semantics of the Integrated Solutions global filesystem from 30 years ago. or the UNC type paths of today.

I think you are misreading what I wrote. POSIX requires that a double slash at the beginning of the path NOT be collapsed. It may not have a special meaning, BUT it can't be assumed redundant by any utils that take a path.

Looks like you missread my text. POSIX _permits_ this behavior, but it does not require it: If the string pointed to by path is exactly "//", it is implementation defined whether "/" or "//" is returned... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org