| blob | a46c6e0d225cb6d72fc01ca3c0218378d8b48f38 |
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
24 ;;; CL:PARSE-ERROR (or more specifically, of type
25 ;;; SB-KERNEL:NAMESTRING-PARSE-ERROR).
30 ;;; some things SBCL-0.6.9 used not to parse correctly:
31 ;;;
32 ;;; SBCL used to throw an error saying there's no translation.
35 ;;; We do not match a null directory to every wild path:
38 ;;; Remove "**" from our resulting pathname when the source-dir is NIL:
43 ;;; That should be correct:
46 ;;; Check for absolute/relative path confusion:
52 ;;; Under SBCL: new function #'UNPARSE-ENOUGH-NAMESTRING, to
53 ;;; handle the following case exactly (otherwise we get an error:
54 ;;; "#'IDENTITY CALLED WITH 2 ARGS."
59 ;;; When a pathname comes from a logical host, it should be in upper
60 ;;; case. (This doesn't seem to be specifically required in the ANSI
61 ;;; spec, but it's left up to the implementors, and the arguments made
62 ;;; in the cleanup issue PATHNAME-LOGICAL:ADD seem to be a pretty
63 ;;; compelling reason for the implementors to choose case
64 ;;; insensitivity and a canonical case.)
75 ;;; In addition to the upper-case constraint above, if the logical-pathname
76 ;;; contains a string component in e.g. the directory, name and type slot,
77 ;;; these should be valid "WORDS", according to CLHS 19.3.1.
78 ;;; FIXME: currently SBCL throws NAMESTRING-PARSE-ERROR: should this be
79 ;;; a TYPE-ERROR?
82 ;; MAKE-PATHNAME is UNSAFELY-FLUSHABLE
88 ;; error: name-component not valid
92 ;; error: type-component not valid.
97 ;;; We may need to parse the host as a LOGICAL-NAMESTRING HOST. The
98 ;;; HOST in PARSE-NAMESTRING can be either a string or :UNSPECIFIC
99 ;;; without actually requiring the system to signal an error (apart
100 ;;; from host mismatches).
104 ;;; The third would work if the call were (and it should continue to
105 ;;; work ...)
111 ;;; ANSI says PARSE-NAMESTRING returns TYPE-ERROR on host mismatch.
115 ;;; turning one logical pathname into another:
121 ;;; ANSI, in its wisdom, specifies that it's an error (specifically a
122 ;;; TYPE-ERROR) to query the system about the translations of a string
123 ;;; which doesn't have any translations. It's not clear why we don't
124 ;;; just return NIL in that case, but they make the rules..
128 (assert (not (string-equal (host-namestring (parse-namestring "OTHER-HOST:ILLEGAL/LPN")) "OTHER-HOST")))
131 ;;; FIXME: A comment on this section up to sbcl-0.6.11.30 or so said
132 ;;; examples from CLHS: Section 19.4, LOGICAL-PATHNAME-TRANSLATIONS
133 ;;; (sometimes converted to the Un*x way of things)
134 ;;; but when I looked it up I didn't see the connection. Presumably
135 ;;; there's some code in this section which should be attributed
136 ;;; to something in the ANSI spec, but I don't know what code it is
137 ;;; or what section of the specification has the related code.
160 ;;; ANSI section 19.3.1.1.5 specifies that translation to a filesystem
161 ;;; which doesn't have versions should ignore the version slot. CMU CL
162 ;;; didn't ignore this as it should, but we do.
166 \f
167 ;;;; MERGE-PATHNAME tests
168 ;;;;
169 ;;;; There are some things we don't bother testing, just because they're
170 ;;;; not meaningful on the underlying filesystem anyway.
171 ;;;;
172 ;;;; Mostly that means that we don't do devices, we don't do versions
173 ;;;; except minimally in LPNs (they get lost in the translation to
174 ;;;; physical hosts, so it's not much of an issue), and we don't do
175 ;;;; hosts except for LPN hosts
176 ;;;;
177 ;;;; Although these tests could conceivably be useful in principle for
178 ;;;; other implementations, they depend quite heavily on the rules for
179 ;;;; namestring parsing, which are implementation-specific. So, success
180 ;;;; or failure in these tests doesn't tell you anything about
181 ;;;; ANSI-compliance unless your PARSE-NAMESTRING works like ours.
183 ;;; Needs to be done at compile time, so that the #p"" read-macro
184 ;;; correctly parses things as logical pathnames. This is not a
185 ;;; problem as was, as this is an impure file and so gets loaded in,
186 ;;; but just for future proofing...
194 ;; If pathname does not specify a host, device, directory,
195 ;; name, or type, each such component is copied from
196 ;; default-pathname.
197 ;; 1) no name, no type
199 ;; 2) no directory, no type
201 ;; 3) no name, no dir (must use make-pathname as ".foo" is parsed
202 ;; as a name)
206 ;; If (pathname-directory pathname) is a list whose car is
207 ;; :relative, and (pathname-directory default-pathname) is a
208 ;; list, then the merged directory is [...]
210 ;; except that if the resulting list contains a string or
211 ;; :wild immediately followed by :back, both of them are
212 ;; removed.
214 ;; "../" in a namestring is parsed as :up not :back, so make-pathname
217 ;; If (pathname-directory default-pathname) is not a list or
218 ;; (pathname-directory pathname) is not a list whose car is
219 ;; :relative, the merged directory is (or (pathname-directory
220 ;; pathname) (pathname-directory default-pathname))
224 ;; === logical pathnames ===
225 ;; recognizes a logical pathname namestring when
226 ;; default-pathname is a logical pathname
227 ;; FIXME: 0.6.12.23 fails this one.
228 ;;
229 ;; And, as it happens, it's right to fail it. Because
230 ;; #p"name1" is read in with the ambient *d-p-d* value, which
231 ;; has a physical (Unix) host; therefore, the host of the
232 ;; default-pathname argument to merge-pathnames is
233 ;; irrelevant. The result is (correctly) different if
234 ;; '#p"name1"' is replaced by "name1", below, though it's
235 ;; still not what one might expect... -- CSR, 2002-05-09
237 ;; or when the namestring begins with the name of a defined
238 ;; logical host followed by a colon [I assume that refers to pathname
239 ;; rather than default-pathname]
241 ;; conduct the previous set of tests again, with a lpn first argument
265 ;; FIXME: test version handling in LPNs
266 )
274 \f
275 ;;; host-namestring testing
285 \f
286 ;;; Bug 200: translate-logical-pathname is according to the spec supposed
287 ;;; not to give errors if asked to translate a namestring for a valid
288 ;;; physical pathname. Failed in 0.7.7.28 and before
291 \f
292 ;;; Not strictly pathname logic testing, but until sbcl-0.7.6.19 we
293 ;;; had difficulty with non-FILE-STREAM stream arguments to pathname
294 ;;; functions (they would cause memory protection errors). Make sure
295 ;;; that those errors are gone:
297 type-error))
299 type-error))
300 \f
301 ;;; ensure read/print consistency (or print-not-readable-error) on
302 ;;; pathnames:
317 \f
318 ;;; BUG 330: "PARSE-NAMESTRING should accept namestrings as the
319 ;;; default argument" ...and streams as well
325 ;; FIXME: This test is a bit flaky, since we only check that
326 ;; no error is signalled. The dilemma here is "what is the
327 ;; correct result when defaults is a _file_, not a
328 ;; directory". Currently (0.8.10.73) we get #P"foo" here (as
329 ;; opposed to eg. #P"/path/to/current/foo"), which is
330 ;; possibly mildly surprising but probably conformant.
334 \f
335 ;;; ENOUGH-NAMESTRING should probably not fail when the namestring in
336 ;;; question has a :RELATIVE pathname.
338 \f
339 ;;; bug reported by Artem V. Andreev: :WILD not handled in unparsing
340 ;;; directory lists.
343 ;;; Printing of pathnames; see CLHS 22.1.3.1. This section was started
344 ;;; to confirm that pathnames are printed as their namestrings under
345 ;;; :escape nil :readably nil.
354 ()
355 "~S should be ~S, was ~S"
357 expected
358 actual))
359 \f
360 ;;; we got (truename "/") wrong for about 6 months. Check that it's
361 ;;; still right.
365 \f
366 ;;; we failed to unparse logical pathnames with :NAME :WILD :TYPE NIL.
367 ;;; (Reported by Pascal Bourguignon.
372 \f
373 ;;; reported by James Y Knight on sbcl-devel 2006-05-17
379 ;;; construct native namestrings even if the directory is empty (means
380 ;;; that same as if (:relative))
388 p))))
390 ;;; reported by Richard Kreuter: PATHNAME and MERGE-PATHNAMES used to
391 ;;; be unsafely-flushable. Since they are known to return non-nil values
392 ;;; only, the test-node of the IF is flushed, and since the function
393 ;;; is unsafely-flushable, out it goes, and bad pathname designators
394 ;;; breeze through.
395 ;;;
396 ;;; These tests rely on using a stream that appears as a file-stream
397 ;;; but isn't a valid pathname-designator.
403 ;;; This used to return "quux/bar.lisp"
410 \f
412 \f
428 ;;; enough-namestring relative to root
430 \f
431 ;;; Check the handling of NIL, :UNSPECIFIC, the empty string, and
432 ;;; non-NIL strings in NATIVE-NAMESTRING implementations. Revised by
433 ;;; RMK 2007-11-28, attempting to preserve the apparent intended
434 ;;; denotation of SBCL's then-current pathname implementation.
437 for name in components
445 #-win32
453 #+win32
460 ;;;; success