to all the language lawyers and paralegals:
(setf (logical-pathname-translations "CL-LIBRARY")
'((";**;*.*.*" "/tmp/lisp/"))))
(make-pathname :defaults "**/*.FASL.*" :host "CL-LIBRARY")
==> ???
CMUCL & Allegro return
#.(logical-pathname #p"CL-LIBRARY:;**;*.FASL.*")
LispWorks barfs.
It is not clear to me that CMUCL & ACL are correct.
1. the presence of "/" instead of ";" in "**/*.FASL.*" is problematic.
2. the lack of initial ";" in "**/*.FASL.*" indicates that this is a
_relative_ path, while both CMUCL and ACL create an absolute path.
comments?
--
Sam Steingold (http://www.podval.org/~sds)
Bill Gates is not god and Microsoft is not heaven.
Sam Steingold <ยทยทยท@gnu.org> writes:
> (setf (logical-pathname-translations "CL-LIBRARY")
> '((";**;*.*.*" "/tmp/lisp/"))))
> (make-pathname :defaults "**/*.FASL.*" :host "CL-LIBRARY")
>
> ==> ???
>
> CMUCL & Allegro return
> #.(logical-pathname #p"CL-LIBRARY:;**;*.FASL.*")
> LispWorks barfs.
It says:
Error: Expected a logical pathname word character at "*.FASL" :start 1.
It's trying to construct a logical pathname whose name component would
be "*.FASL", and quite properly complaining that #\. is an illegal
character in a logical pathname word. This happens because the
defaults argument is parsed as a physical namestring, and in it, the
last #\. is taken to separate name and type (there's no version
component in the Unix namestring syntax). I think this is reasonable;
there's nothing in the standard to indicate the :HOST argument should
affect the parsing of :DEFAULTS.
> It is not clear to me that CMUCL & ACL are correct.
>
> 1. the presence of "/" instead of ";" in "**/*.FASL.*" is problematic.
They are, like LW, parsing this as physical. The difference with LW
is, apparently, that they think Unix pathnames have versions and parse
the tail as :NAME "*" :TYPE "FASL" :VERSION "*".
> 2. the lack of initial ";" in "**/*.FASL.*" indicates that this is a
> _relative_ path, while both CMUCL and ACL create an absolute path.
You meant that the other way round: ";" indicates a _relative_ path.
The answer is the same: It's parsed as a physical namestring, so it
designates a relative path. This is then merged into the result, a
logical pathname with just the host, and you still have a relative
result.
So, all implementations are correct; it's just not a portable idiom.
You might be better off using PARSE-PATHNAME, but I don't know what
you're trying to accomplish.
--
Pekka P. Pirinen
I believe in UFOs: _Unidentified_ Flying Objects.