Directory Filenames – Path Syntax Rules

directoryfilenames

I'm writing a library for manipulation Unix path strings. That being the case, I need to understand a few obscure corners of the syntax that most people wouldn't worry about.

For example, as best as I can tell, it seems that foo/bar and foo//bar both point to the same place.

Also, ~ usually stands for the user's home directory, but what if it appears in the middle of a path? What happens then?

These and several dozen other obscure questions need answering if I'm going to write code which handles every possible case correctly. Does anybody know of a definitive reference which explains the exact syntax rules for this stuff?

(Unfortunately, searching for terms like "Unix path syntax" just turns up a million pages discussing the $PATH variable… Heck, I'm even struggling to find suitable tags for this question!)

Best Answer

There are three types of paths:

relative paths like foo, foo/bar, ../a, .. They don't start with / and are relative to the current directory of the process making a system call with that path.
absolute paths like /, /foo/bar or ///x. They start with 1, or 3 or more /, they are not relative, are looked up starting from the / root directory.
POSIX allows //foo to be treated specially, but doesn't specify how. Some systems use that for special cases like network files. It has to be exactly 2 slashes.

Other than at the start, sequences of slashes act like one.

~ is only special to the shell, it's expanded by the shell, it's not special to the system at all. How it's expanded is shell dependent. Shells do other forms of expansions like globbing (*.txt) or variable expansion /$foo/$bar or others. As far as the system is concerned ~foo is just a relative path like _foo or foo.

Things to bear in mind:

foo/ is not the same as foo. It's closer to foo/. than foo (especially if foo is a symlink) for most system calls on most systems (foo// is the same as foo/ though).
a/b/../c is not necessarily the same as a/c (for instance if a/b is a symlink). Best is not to treat .. specially.
it's generally safe to consider a/././././b the same as a/b though.

Related Solutions

Linux – How Does Linux Handle Multiple Consecutive Path Separators?

Multiple slashes are allowed and are equivalent to a single slash. From the Single Unix specification (version 4), base definitions §3.271 pathname: “Multiple successive slashes are considered to be the same as one slash.”

There is one exception: If a pathname begins with two successive slash characters, the first component following the leading slash characters may be interpreted in an implementation-defined manner. (ref: base definitions §4.13 pathname resolution). Linux itself doesn't do this, though some applications might, and other unix-ish system do (e.g. Cygwin).

A trailing / at the end of a pathname forces the pathname to refer to a directory. In (POSIX 1003.1-2001 (Single Unix v4) base definitions §4.11 pathname resolution, a trailing / is equivalent to a trailing /.. POSIX 1003.1-2008 (Single Unix v4) base definitions §4.13 removes the requirement to make it equivalent to /., in order to cope with non-existing directories (e.g. mkdir foo/ is required to work, whereas mkdir foo/. wouldn't — see the rationale for the change).

For programs that act on a directory entry, if foo is a symbolic link to a directory, then passing foo/ is a way to make the program act on the directory instead of the symbolic link.

¹ _{Note that this applies for pathname resolution only, i.e. when accessing files. Filename manipulations may work differently. For example basename and dirname ignore trailing slashes.}

Open files in emacs by filename instead of complete path

As I write this, I discover ifind-mode, which looks spot on.

(setq workspace-dir "/path/to/dir1 /path/to/dir2")
(require 'ifind-mode)
;; maybe change `ifind-command' as well

Then type M-x ifind-mode to find a file in the specified directories (and subdirectories by default), with nifty completion.

What I usually do is e **/bar from zsh (where e is an alias for emacsclient). But that's disruptive if you're in Emacs already. Also, if there's a specific file I edit often, I leave it open (and I save my session).

Out of the box, you can run M-x find-dired and specify arguments to find. But that's clumsy, at least for the case when you have a single match. ifind makes this less clumsy.

ido has a bunch of features that may be useful, especially Use ido to find any file from the project.

Best Answer

Related Solutions

Linux – How Does Linux Handle Multiple Consecutive Path Separators?

Open files in emacs by filename instead of complete path

Related Question