meaning of '//' in path/file

E

Erichans

I'm unclear about:
Code: 
# ls -il  /usr/local/etc/pkg/repos/FreeBSD.conf  /usr/local/etc/pkg/repos//FreeBSD.conf
34118738 -rw-r--r--  1 root wheel 1151 Feb 25 12:03 /usr/local/etc/pkg/repos//FreeBSD.conf
34118738 -rw-r--r--  1 root wheel 1151 Feb 25 12:03 /usr/local/etc/pkg/repos/FreeBSD.conf
# file  /usr/local/etc/pkg/repos/FreeBSD.conf  /usr/local/etc/pkg/repos//FreeBSD.conf
/usr/local/etc/pkg/repos/FreeBSD.conf:  ASCII text
/usr/local/etc/pkg/repos//FreeBSD.conf: ASCII text
I was expecting an error with the // in the path specification but it seems legal.
It seems that the number of /-es as separator does not matter:
basename /usr/local/etc/pkg//repos////FreeBSD.conf
works equally 'well'.

Is this a Unix or FreeBSD thing and is this documented somewhere?
 
it is a a valid path separator but since there is nothing in it it can be thought of as null...Many times when building code and reading env vars there is a question of whether a path type env var ends with a / and will have additional path appended to it. Having to check if the last character is / would be tiresome so the unix gods many eons ago gave law, and it was good.

I'm not sure if it is explicitly documented or more documented by example. It is a long time UNIX thing though.
 
As far as I understand FreeBSD’s notion of pathname complies with POSIX.​
[…] Multiple successive <slash> characters are considered to be the same as one <slash>, except it is implementation‐defined whether the case of exactly two leading <slash> characters is treated specially.
Click to expand...
The FreeBSD operating system does not (seem to) treat leading double‑slashes specially, cmp. intro(2) “Path Name” in § Definitions.​
Erichans said:
[…] It seems that the number of /-es as separator does not matter: […]
Click to expand...
Well, it still has to be non‐zero.​
 
kent_dorfman766 said:
Many times when building code and reading env vars there is a question of whether a path type env var ends with a / and will have additional path appended to it. Having to check if the last character is / would be tiresome so the unix gods many eons ago gave law, and it was good.

I'm not sure if it is explicitly documented or more documented by example. It is a long time UNIX thing though.
Click to expand...
Indeed. Though for my own code I tend to be pedantic, I feel it to be too sloppy if it ends up relying on the '//' lenience and try to avoid it.
 
Erichans said:
Is this a Unix or FreeBSD thing and is this documented somewhere?
Click to expand...
It goes back to the earliest versions of AT&T Unix, and the implementation of the kernel nami() function which parsed path names. Multiple slashes were ignored.

On another aspect of nami(), Dennis Ritchie reacted publicly with some distress when the USG changed the null file name to be invalid. The original paper on V6 made it very clear that "the null file name refers to the current directory".
 
You must log in or register to reply here.
Back
Top