Partly-wild logical pathname components don't work
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SBCL |
New
|
Undecided
|
Unassigned |
Bug Description
Given a logical host defined as
(setf (logical-
`
:name :wild :type :wild :version :wild)
Then
(parse-namestring "FUNGE:
Works. But
(make-pathname :host "FUNGE"
Raises an error (sb-kernel:
But in fact it is valid I am almost sure: From http://
It's possible that the intention is that any string for a name (or other component) can never denote a wildcard, but that makes constructing pathnames extremely painful if they have name components like "*-FOO" say: I can't see any way of constructing such a pathname which does not involve jumping through enormous hoops (parsing a namestring, extracting the name from it, putting this back into another pathname).
If that is the case then this isn't a bug.
SBCL version: 2.0.6
uname -a:
Linux ts 5.4.0-40-generic #44-Ubuntu SMP Tue Jun 23 00:01:04 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
*features*
(:swank :org.tfeb.
:asdf3 :asdf2 :asdf :os-unix :non-base-
:gencgc :64-bit :ansi-cl :common-lisp :elf :ieee-floating-
:little-endian :package-
:sb-unicode :sbcl :unix)
Here's a go at the argument that this is a conformance issue:
A.1. 19.3.1.6 says wildcard-words parse as strings, and so it ought to be the case that
(pathname-name #P"SYS:A;B*")
=> "B*"
A.2. 19.2.2.5 says ``Any component can be taken from the corresponding component of another pathname.''
Therefore, it seems that the domain of NAME arguments for logical pathnames constructible by MAKE-PATHNAME [*] ought to be at least the range of name components that can be the result of a logical pathname parse. And so
(make-pathname :name "B*" :defaults #P"SYS:A;")
ought to work.
I guess one swing some counterargument that 19.3.1.6's phrase ``other wildcard-words parse into strings'' doesn't explicitly say that the resulting component will /be/ (or contain, for the directory) a string. That seems a little tortured.
[*] It's anybody's guess whether MAKE-PATHNAME is required to be able to construct logical pathnames. The HOST argument is defined to be a ``valid physical pathname host''. It would be intuitive to suppose, based on the concepts' names, that ``valid physical pathname host'' and ``valid logical pathname host'' ought to be a partition of ``valid pathname host'', but they're not explicitly said to be disjoint, and ``valid physical pathname host'' is defined as an object ``that is recognized by the implementation as the name of a host'', and so could be construed to include all valid logical pathname hosts (making the ``or a valid logical pathname host'' in the definition of ``valid pathname host'' redundant). But that's an orthogonal defect in the standard.
Further if you suppose that MAKE-PATHNAME really isn't supposed to be able to take logical host designator, i.e., it's permitted of an implementation to have that be a type error, then it's unclear what's supposed to happen if the DEFAULTS argument is a logical pathname and HOST is unsupplied. That's maybe a second orthogonal defect.
(Btw., that :DEFAULTS NIL in your example is definitely not kosher.)