(let ((*dpd* #p"")) (truename #p"")) error

[Faré]

* (require "asdf") (in-package :asdf)

* (implementation-identifier)
;==> "sbcl-1.2.12.61-9741c60-dirty-linux-x64"

* (setf *default-pathname-defaults* #p"")

* (equal (getcwd) (truename #p"."))
;==> T

* (truename #p"")
;==!> (SB-IMPL::SIMPLE-FILE-PERROR "Failed to find the TRUENAME of ~A" #P"" 2)

I would expect #p"" to behave like #p"." and truename to not yield an error but to return the getcwd.

[Richard M Kreuter (kreuter)]

As the guy who once upon a time wrote the code that signals this error, I don't know if I thought of this specific case at the time, but here's how I thought things ought to work then:

A. A physical pathname denotes a filename via SB-EXT:NATIVE-NAMESTRING. A physical pathname whose non-host components are all NIL (or irrelevant), maps to an empty filename, i.e., "", under SB-EXT:NATIVE-NAMESTRING. (Not all physical pathnames denote filenames: wild pathnames, pathnames with NIL for the name, and maybe some others don't..)

B. A filename, in turn, means whatever the underlying operating system routines say it does.

C. POSIX pathname resolution defines that an empty string does not resolve; Consequently, the relevant file system calls fail and set errno. (I don't know what the Win32 APIs say; at that time SBCL was mostly employing POSIX APIs on Windows.)

D. When file system calls fail and ANSI (or maybe backward compatibility [*]) doesn't say to do otherwise, Lisp ought to signal a FILE-ERROR. (Cf.: by analogy, if the pathname mapped to a filename whose basename name were too long, rather than maximally short, the OS routines would also fail and communicate via errno, and it seems reasonable that Lisp should signal a FILE-ERROR in that case.)

To summarize, in this model (which I never wrote down, nor do I claim any other SBCL maintainer ever endorsed), pathnames that map to filenames don't have semantics of their own; the OS supplies such pathnames meaning by assigning meaning to the mapped filenames. (I started, but never finished, threading this kind of model through OPEN, which happens to open(2) the cwd when the post-merge, post-translation pathname is #P"". Whatever one thinks of the model I tried to fit TRUENAME/FILE-WRITE-DATE/etc. into, that observable inconsistency with OPEN is unfortunate. And of course DIRECTORY, which most often takes a pathname that doesn't map to a filename, offers semantics that SBCL invents from whole cloth.)

Anyway, as for your request, having Lisp invent denotations for empty pathnames is a bit ``magical'' for my taste. But since I don't use pathnames that way, I'd never rely on that behavior, so allowing it seems harmless (and seemingly compatible with many other implementations).

[*] In SBCL, backward compatibility considerations overrode the definition of DIRECTORY in a way that infected TRUENAME: in SBCL, DIRECTORY does not signal errors. Because SBCL's DIRECTORY applies TRUENAME to files that exist, SBCL's TRUENAME is defined not to error when the argument exists but is a dangling or circular symlink. So TRUENAME does have some ad hoc and hokey semantics in general.

[Faré (fahree)]

Most Lisp implementations (at least Allegro, CCL, CMUCL, CLISP, ECL, LispWorks, MKCL) agree that #p"", which has NIL slots for DIRECTORY, FILENAME, TYPE and DEVICE (but the current HOST), represents the current directory (on the current HOST), since overriding the DIRECTORY, FILENAME or TYPE behaves just like looking things up in the current directory.

On the other hand, ABCL agrees with SBCL that this is an error.