| blob | e2c200e8a09c20781caa70ab533efffed65d78fc |
1 ;;;; miscellaneous tests of pathname-related stuff
3 ;;;; This file is naturally impure because we mess with
4 ;;;; LOGICAL-PATHNAME-TRANSLATIONS.
6 ;;;; This software is part of the SBCL system. See the README file for
7 ;;;; more information.
8 ;;;;
9 ;;;; While most of SBCL is derived from the CMU CL system, the test
10 ;;;; files (like this one) were written from scratch after the fork
11 ;;;; from CMU CL.
12 ;;;;
13 ;;;; This software is in the public domain and is provided with
14 ;;;; absolutely no warranty. See the COPYING and CREDITS files for
15 ;;;; more information.
23 ;;; In case of a parse error we want to get a condition of type TYPE-ERROR,
24 ;;; because ANSI says so. (This used to be PARSE-ERROR.)
29 ;;; some things SBCL-0.6.9 used not to parse correctly:
30 ;;;
31 ;;; SBCL used to throw an error saying there's no translation.
34 ;;; We do not match a null directory to every wild path:
37 ;;; Remove "**" from our resulting pathname when the source-dir is NIL:
42 ;;; That should be correct:
45 ;;; Check for absolute/relative path confusion:
51 ;;; Under SBCL: new function #'UNPARSE-ENOUGH-NAMESTRING, to
52 ;;; handle the following case exactly (otherwise we get an error:
53 ;;; "#'IDENTITY CALLED WITH 2 ARGS."
58 ;;; When a pathname comes from a logical host, it should be in upper
59 ;;; case. (This doesn't seem to be specifically required in the ANSI
60 ;;; spec, but it's left up to the implementors, and the arguments made
61 ;;; in the cleanup issue PATHNAME-LOGICAL:ADD seem to be a pretty
62 ;;; compelling reason for the implementors to choose case
63 ;;; insensitivity and a canonical case.)
74 ;;; In addition to the upper-case constraint above, if the logical-pathname
75 ;;; contains a string component in e.g. the directory, name and type slot,
76 ;;; these should be valid "WORDS", according to CLHS 19.3.1.
77 ;;; FIXME: currently SBCL throws NAMESTRING-PARSE-ERROR: should this be
78 ;;; a TYPE-ERROR?
81 ;; MAKE-PATHNAME is UNSAFELY-FLUSHABLE
87 ;; error: name-component not valid
91 ;; error: type-component not valid.
96 ;;; We may need to parse the host as a LOGICAL-NAMESTRING HOST. The
97 ;;; HOST in PARSE-NAMESTRING can be either a string or :UNSPECIFIC
98 ;;; without actually requiring the system to signal an error (apart
99 ;;; from host mismatches).
103 ;;; The third would work if the call were (and it should continue to
104 ;;; work ...)
110 ;;; ANSI says PARSE-NAMESTRING returns TYPE-ERROR on host mismatch.
114 ;;; turning one logical pathname into another:
120 ;;; ANSI, in its wisdom, specifies that it's an error (specifically a
121 ;;; TYPE-ERROR) to query the system about the translations of a string
122 ;;; which doesn't have any translations. It's not clear why we don't
123 ;;; just return NIL in that case, but they make the rules..
127 (assert (not (string-equal (host-namestring (parse-namestring "OTHER-HOST:ILLEGAL/LPN")) "OTHER-HOST")))
130 ;;; FIXME: A comment on this section up to sbcl-0.6.11.30 or so said
131 ;;; examples from CLHS: Section 19.4, LOGICAL-PATHNAME-TRANSLATIONS
132 ;;; (sometimes converted to the Un*x way of things)
133 ;;; but when I looked it up I didn't see the connection. Presumably
134 ;;; there's some code in this section which should be attributed
135 ;;; to something in the ANSI spec, but I don't know what code it is
136 ;;; or what section of the specification has the related code.
159 ;;; ANSI section 19.3.1.1.5 specifies that translation to a filesystem
160 ;;; which doesn't have versions should ignore the version slot. CMU CL
161 ;;; didn't ignore this as it should, but we do.
165 \f
166 ;;;; MERGE-PATHNAME tests
167 ;;;;
168 ;;;; There are some things we don't bother testing, just because they're
169 ;;;; not meaningful on the underlying filesystem anyway.
170 ;;;;
171 ;;;; Mostly that means that we don't do devices, we don't do versions
172 ;;;; except minimally in LPNs (they get lost in the translation to
173 ;;;; physical hosts, so it's not much of an issue), and we don't do
174 ;;;; hosts except for LPN hosts
175 ;;;;
176 ;;;; Although these tests could conceivably be useful in principle for
177 ;;;; other implementations, they depend quite heavily on the rules for
178 ;;;; namestring parsing, which are implementation-specific. So, success
179 ;;;; or failure in these tests doesn't tell you anything about
180 ;;;; ANSI-compliance unless your PARSE-NAMESTRING works like ours.
182 ;;; Needs to be done at compile time, so that the #p"" read-macro
183 ;;; correctly parses things as logical pathnames. This is not a
184 ;;; problem as was, as this is an impure file and so gets loaded in,
185 ;;; but just for future proofing...
193 ;; If pathname does not specify a host, device, directory,
194 ;; name, or type, each such component is copied from
195 ;; default-pathname.
196 ;; 1) no name, no type
198 ;; 2) no directory, no type
200 ;; 3) no name, no dir (must use make-pathname as ".foo" is parsed
201 ;; as a name)
205 ;; If (pathname-directory pathname) is a list whose car is
206 ;; :relative, and (pathname-directory default-pathname) is a
207 ;; list, then the merged directory is [...]
209 ;; except that if the resulting list contains a string or
210 ;; :wild immediately followed by :back, both of them are
211 ;; removed.
213 ;; "../" in a namestring is parsed as :up not :back, so make-pathname
216 ;; If (pathname-directory default-pathname) is not a list or
217 ;; (pathname-directory pathname) is not a list whose car is
218 ;; :relative, the merged directory is (or (pathname-directory
219 ;; pathname) (pathname-directory default-pathname))
223 ;; === logical pathnames ===
224 ;; recognizes a logical pathname namestring when
225 ;; default-pathname is a logical pathname
226 ;; FIXME: 0.6.12.23 fails this one.
227 ;;
228 ;; And, as it happens, it's right to fail it. Because
229 ;; #p"name1" is read in with the ambient *d-p-d* value, which
230 ;; has a physical (Unix) host; therefore, the host of the
231 ;; default-pathname argument to merge-pathnames is
232 ;; irrelevant. The result is (correctly) different if
233 ;; '#p"name1"' is replaced by "name1", below, though it's
234 ;; still not what one might expect... -- CSR, 2002-05-09
236 ;; or when the namestring begins with the name of a defined
237 ;; logical host followed by a colon [I assume that refers to pathname
238 ;; rather than default-pathname]
240 ;; conduct the previous set of tests again, with a lpn first argument
264 ;; FIXME: test version handling in LPNs
265 )
273 \f
274 ;;; host-namestring testing
284 \f
285 ;;; Bug 200: translate-logical-pathname is according to the spec supposed
286 ;;; not to give errors if asked to translate a namestring for a valid
287 ;;; physical pathname. Failed in 0.7.7.28 and before
290 \f
291 ;;; Not strictly pathname logic testing, but until sbcl-0.7.6.19 we
292 ;;; had difficulty with non-FILE-STREAM stream arguments to pathname
293 ;;; functions (they would cause memory protection errors). Make sure
294 ;;; that those errors are gone:
296 type-error))
298 type-error))
299 \f
300 ;;; ensure read/print consistency (or print-not-readable-error) on
301 ;;; pathnames:
316 \f
317 ;;; BUG 330: "PARSE-NAMESTRING should accept namestrings as the
318 ;;; default argument" ...and streams as well
324 ;; FIXME: This test is a bit flaky, since we only check that
325 ;; no error is signalled. The dilemma here is "what is the
326 ;; correct result when defaults is a _file_, not a
327 ;; directory". Currently (0.8.10.73) we get #P"foo" here (as
328 ;; opposed to eg. #P"/path/to/current/foo"), which is
329 ;; possibly mildly surprising but probably conformant.
333 \f
334 ;;; ENOUGH-NAMESTRING should probably not fail when the namestring in
335 ;;; question has a :RELATIVE pathname.
337 \f
338 ;;; bug reported by Artem V. Andreev: :WILD not handled in unparsing
339 ;;; directory lists.
342 ;;; Printing of pathnames; see CLHS 22.1.3.1. This section was started
343 ;;; to confirm that pathnames are printed as their namestrings under
344 ;;; :escape nil :readably nil.
353 ()
354 "~S should be ~S, was ~S"
356 expected
357 actual))
358 \f
359 ;;; we got (truename "/") wrong for about 6 months. Check that it's
360 ;;; still right.
364 \f
365 ;;; we failed to unparse logical pathnames with :NAME :WILD :TYPE NIL.
366 ;;; (Reported by Pascal Bourguignon.
371 \f
372 ;;; reported by James Y Knight on sbcl-devel 2006-05-17
378 ;;; construct native namestrings even if the directory is empty (means
379 ;;; that same as if (:relative))
387 p))))
389 ;;; reported by Richard Kreuter: PATHNAME and MERGE-PATHNAMES used to
390 ;;; be unsafely-flushable. Since they are known to return non-nil values
391 ;;; only, the test-node of the IF is flushed, and since the function
392 ;;; is unsafely-flushable, out it goes, and bad pathname designators
393 ;;; breeze through.
394 ;;;
395 ;;; These tests rely on using a stream that appears as a file-stream
396 ;;; but isn't a valid pathname-designator.
402 ;;; This used to return "quux/bar.lisp"
409 \f
411 \f
427 ;;; enough-namestring relative to root
429 \f
430 ;;; Check the handling of NIL, :UNSPECIFIC, the empty string, and
431 ;;; non-NIL strings in NATIVE-NAMESTRING implementations. Revised by
432 ;;; RMK 2007-11-28, attempting to preserve the apparent intended
433 ;;; denotation of SBCL's then-current pathname implementation.
436 for name in components
444 #-win32
452 #+win32
481 ;;; Reported by Willem Broekema: Reading #p"\\\\" caused an error due
482 ;;; to insufficient sanity in input testing in EXTRACT-DEVICE (in
483 ;;; src;code;win32-pathname).
484 #+win32
500 f))
508 translations))
521 ;;;; success