On 16 Feb 2014, at 10:43 PM, Martin Mallinson wrote:
Dear SBCl team:
I believe this is not expected and represents a bug in both Window
and Linux versions.
(I do not have quite the latest version on Linux bit I hope this is
* (make-pathname :name "example*" :type "txt")
The expected result is as returned by ACL and ABCL for example is:
C:\Users\Martin\Downloads>java -jar abcl.jar
Armed Bear Common Lisp 1.3.0-dev
Java 1.7.0_51 Oracle Corporation
Java HotSpot(TM) Client VM
Low-level initialization completed in 0.331 seconds.
Startup completed in 4.297 seconds.
Type ":help" for a list of available commands.
CL-USER(1): (make-pathname :name "example*" :type "txt")
You may appreciate the error in this interaction:
CL-USER> (directory "plot*.dat")
CL-USER> (directory (make-pathname :name "plot*" :type
The result, of course, should be the same in both cases...
(since the file "plot00.dat" does exist)
this is no reason to expect that the results of the two forms should be the same.
the requirements for physical pathnames with respect to parsing, representation, and interpretation[2,3] are sufficiently non-specific, that such expectations cannot follow from the language specification. one might, on the other hand, expect an implementation to fulfill certain expectations with respect to designating files and matching sets of files. in a number of cases, the distinction made by the sbcl runtime between these two examples with respect to identifying and manipulating files to be quite purposeful
* (pathname "test*.txt")
* (pathname-name *)
#<SB-IMPL::PATTERN "test" :MULTI-CHAR-WILD>
* (make-pathname :name "test*" :type "txt")
in the first case, "the parsing of the thing is implementation defined", while in the other, the implementation constructs the literal combination of the arguments, which - at least from some points of view, is to be expected and enables the application to identify such files, as in
* (probe-file #p"test\\*.txt")
best regards, from berlin,