Duncan Coutts wrote:
Some people have mentioned before that some systems (though not the native low level POSIX interfaces) do actually distinguish "./blah/blah" from "blah/blah". The distinction is whether a file is relative to the current directory or to some other unspecified root (eg a search path). Unix shells make this distinction for example when running "a.out" vs "./a.out". The latter is independent of the current $PATH, it really refers to the one in the current directory, not any such file on the $PATH.
Just for reference, this comes up with shell settings other than just $PATH as well. For instance, cd in Bash looks through $CDPATH in the same way command selection looks through $PATH (i.e. the default value is "." which is sensible, but some folks like ".:~" to make their home dir everywhere, and you can do crazier things). And various other programs have their own $*PATH variables.
On a related note, when I have experimented with designing a typed version of FilePath, one of the things I wanted to distinguish in the types is exactly this thing about "relative to something specific" (eg relative to "/" or ".") vs "relative to something not yet specified". Another terminology might be "complete" and "incomplete". The OS file manipulation functions would only work on complete filepaths.
I like this distinction. Regardless of the settlement of "" vs "./", it is helpful to distinguish "paths being built" (and therefore potentially invalid) from "real paths" anchored to the file system. -- Live well, ~wren