On Sep 25, 2010, at 7:11 AM, Antoine Pitrou wrote:
On Sun, 26 Sep 2010 00:00:57 +1000 Ben Finney firstname.lastname@example.org wrote:
Antoine Pitrou email@example.com writes:
Again, why not simply improve realpath()?
Because that already does what it says it does.
So what? The behaviour of fetching the canonical name can be added to the behaviour of resolving symlinks. It wouldn't be incompatible with the current behaviour AFAICT. And it would be better than adding yet another function to our ménagerie of path-normalizing functions. We already have abspath(), normpath(), normcase(), realpath() -- all with very descriptive names as you might notice. We don't need another function.
realpath's docs describe its result as "the canonical path of the specified filename, eliminating any symbolic links encountered in the path (if they are supported by the operating system)".
"Canonical" should describe the behavior we're after, with the correct case of the filename as it is actually stored on disk.
But isn't realpath modeled after POSIX realpath(3)? realpath(3) doesn't seem to clearly guarantee the original name as stored on disk either. However realpath(3) on OSX 10.6 with case-insensitive HFS+ does return the original name as it was stored. Do any other platforms do this and do we care about maintaining parity with realpath(3)?
-- Philip Jenvey