Subject: Re: A portable DIRECTORY-P. Re: Here we go again. More CMUCL/ACL pathname differences. From: Erik Naggum <erik@naggum.no> Date: 1999/01/16 Newsgroups: comp.lang.lisp Message-ID: <3125448139535882@naggum.no> * vnikolov@poboxes.com | I said that the answer is yes (implementation-dependent); | if you say the answer is no, would you please demonstrate why not? this is entirely faulty reasoning. my point is that the case of the logical pathname is defined and constrained in the standard. whatever is left is a candidate for implementation-defined parsing as a physical pathname, not as a logical pathname, since that has been exhaustively defined. the case you have brought up is nowhere near the conditions for parsing as a logical pathname. I have to ask you why you think this is a valid example in the first place. NIL would have to be a logical host in some implementations and not in others for this example to make sense, if I read it right. that is clearly not a tenable position. | There are two cases: | (1) X is parsed as a logical pathname namestring but the programmer | would like it to be parsed as a physical pathname namestring; | (2) X is parsed as a physical pathname namestring but the programmer | would like it to be parsed as a logical pathname namestring. | Above, you discuss (1), don't you? My concern, however, was with (2). | (Why did you write as if my concern was with (1)?) because 2 is excluded by the standard and it doesn't make sense to discuss settled issues. if you were not aware that it was settled, that's a slightly different discussion than one where you assume it not settled and want to discuss consequences of it not being settled. | (One more thing: although (1) is not my problem, it could well be | somebody's problem when namestrings are supplied to a program from | outside as data (at run-time). The one who supplies them may want them | to be treated as physical pathnames.) true, and this has been what I've been trying to address, since the reverse situation doesn't happen. it appears to me that a HOST argument that is neither a logical host nor NIL should force parsing as a physical pathname. | Is "foo;bar;baz.quux" a logical pathname namestring? no. (I assume that this is the crux of your argumentation.) | The syntax for logical pathname namestring makes the host part optional. no. the host is optional when _otherwise_ provided to PARSE-NAMESTRING. all logical pathnames have a logical host as their host component. if it is optional, it has to come from somewhere, it cannot be assumed, and it cannot be NIL. physical pathnames, on the other hand, may have a NIL host component. | Now, let me point out one reason why I say that is not so trivial. | PARSE-NAMESTRING needs a <host> and a <default-pathname> (not supplied | above) in order to do the right thing in all cases when <namestring> | should be parsed as a logical pathname namestring. (This means that | LOGICAL-PATHNAME-NAMESTRING-P may also need additional arguments.) the `default-pathname' argument defaults to *DEFAULT-PATHNAME-DEFAULTS*, so that's more or less taken care of. if you intend to parse against a particular logical host and take advantage of the then optional host component, you ask a different question than "is this a logical pathname namestring?" your question is now "is this a logical pathname namestring for the given host?" in other words, you'll get a negative reply to all logical pathname namestrings that have a host mismatch. I don't think the function that returns that answer should be called LOGICAL-PATHNAME- NAMESTRING-P. furthermore, I think PARSE-NAMESTRING is sufficient for this more complicated case, and I see no reason why it is not sufficient for the general case, which is why I think nobody has thought of making it part of the standard. you may find lower-level functions used to implement PARSE-NAMESTRING that test for logical pathname namestring syntax if you look for them, however. I'm not sure it's a good idea to call them from user code even if you find them. #:Erik