From: Raymond T. <ray...@er...> - 2008-12-18 17:56:04
|
Let's say we have: (setf (logical-pathname-translations "foo") '(("**;*.*.*" #p"/tmp/**/*.*"))) Is there any way to make (typep <something> 'logical-pathname) be T? (Well, short of using #S(logical-pathname ...).) I'm not exactly sure how translate-logical-pathname can work according to the spec: Pathname is first coerced to a pathname. If the coerced pathname is a physical pathname, it is returned. If the coerced pathname is a logical pathname, the first matching translation (according to pathname-match-p) of the logical pathname host is applied, as if by calling translate-pathname. If the result is a logical pathname, this process is repeated. When the result is finally a physical pathname, it is returned. If no translation matches, an error is signaled. (pathname "foo:abc.lisp") returns a physical pathname and hence translate-logical-pathname should return #p"foo:abc.lisp". Instead (translate-logical-pathname "foo:abc.lisp") returns #P"/tmp/abc.lisp", which seems not right, but, of course, the useful answer. BTW, this is clisp 2.47, on Solaris. Ray |
From: Sam S. <sd...@gn...> - 2008-12-18 18:05:29
|
Raymond Toy wrote: > > Is there any way to make (typep <something> 'logical-pathname) be T? (logical-pathname "foo:bar;baz.zot") > I'm not exactly sure how translate-logical-pathname can work according > to the spec: > > Pathname is first coerced to a pathname. If the coerced pathname > is a physical pathname, it is returned. If the coerced pathname is > a logical pathname, the first matching translation (according to > pathname-match-p) of the logical pathname host is applied, as if > by calling translate-pathname. If the result is a logical > pathname, this process is repeated. When the result is finally a > physical pathname, it is returned. If no translation matches, an > error is signaled. > > (pathname "foo:abc.lisp") returns a physical pathname and hence > translate-logical-pathname should return #p"foo:abc.lisp". Instead > (translate-logical-pathname "foo:abc.lisp") returns #P"/tmp/abc.lisp", > which seems not right, but, of course, the useful answer. translate-logical-pathname always returns a physical pathname - that's its raison d'etre. whether (pathname "foo:abc.lisp") returns a logical or a physical pathname depends on CUSTOM:*PARSE-NAMESTRING-ANSI*, see http://clisp.cons.org/impnotes/filename-misc.html#parsename |
From: Raymond T. <ray...@er...> - 2008-12-18 18:29:18
|
>>>>> "Sam" == Sam Steingold <sd...@gn...> writes: Sam> Raymond Toy wrote: >> Is there any way to make (typep <something> 'logical-pathname) be T? Sam> (logical-pathname "foo:bar;baz.zot") How silly of me! I didn't see that. >> I'm not exactly sure how translate-logical-pathname can work according >> to the spec: >> Pathname is first coerced to a pathname. If the coerced pathname >> is a physical pathname, it is returned. If the coerced pathname is >> a logical pathname, the first matching translation (according to >> pathname-match-p) of the logical pathname host is applied, as if >> by calling translate-pathname. If the result is a logical >> pathname, this process is repeated. When the result is finally a >> physical pathname, it is returned. If no translation matches, an >> error is signaled. >> (pathname "foo:abc.lisp") returns a physical pathname and hence >> translate-logical-pathname should return #p"foo:abc.lisp". Instead >> (translate-logical-pathname "foo:abc.lisp") returns #P"/tmp/abc.lisp", >> which seems not right, but, of course, the useful answer. Sam> translate-logical-pathname always returns a physical pathname - that's Sam> its raison d'etre. Yes, but the spec says it's coerced to a pathname first, so "foo:abc.lisp" is converted to the phyiscal pathname, which is what translate-logical-pathname should return. But I now understand why clisp doesn't return #p"foo:abc.lisp". If it did, translate-logical-pathname would be useless on clisp if it did convert to a pathname first. Sam> whether (pathname "foo:abc.lisp") returns a logical or a physical Sam> pathname depends on CUSTOM:*PARSE-NAMESTRING-ANSI*, see Sam> http://clisp.cons.org/impnotes/filename-misc.html#parsename I did look through the impnotes before sending this. I just missed the stuff about parse-namestring and such. Is it really confusing about parsing "c:/autoexec.bat", "home:.clisprc", and "prep:/pub/gnu" according to ANSI rules? Well, I guess you'd need to look to see if you have logical hosts names "c", "home" or "prep". And I guess the parsing would change if you suddenly defined logical hosts. But people don't really do that except to play games and screw things up intentionally. :-) But "prep:/pub/gnu" clearly can't be a logical pathname because it has illegal characters. Ray |
From: Raymond T. <ray...@er...> - 2008-12-18 23:38:11
|
>>>>> "Raymond" == Raymond Toy <ray...@er...> writes: Raymond> But "prep:/pub/gnu" clearly can't be a logical pathname because it has Raymond> illegal characters. Oops, I'm wrong. "prep:/pub/gnu" isn't illegal. But it is undefined, according to CLHS 19.3.1.1.8 if it's being used as a logical pathname namestring. Ray |
From: Sam S. <sd...@gn...> - 2008-12-22 15:54:23
|
Raymond Toy wrote: >>>>>> "Raymond" == Raymond Toy <ray...@er...> writes: > > Raymond> But "prep:/pub/gnu" clearly can't be a logical pathname because it has > Raymond> illegal characters. > > Oops, I'm wrong. "prep:/pub/gnu" isn't illegal. But it is undefined, > according to CLHS 19.3.1.1.8 if it's being used as a logical pathname > namestring. yes. so prep:clisp could be a symbolic link to to the latest clisp release prep:/pub/gnu/clisp/latest/clisp-2.47.tar.gz and it would be a valid logical pathname and not a network path. I find this to be just on of the many problems with the pathname spec (my pet peeve is that the #s(pathname ...) notation is not standard for readable output despite being used in the examples). |
From: Raymond T. <ray...@er...> - 2008-12-22 18:29:19
|
Sam Steingold wrote: > Raymond Toy wrote: >> Sam Steingold wrote: >>> yes. so prep:clisp could be a symbolic link to to the latest clisp >>> release prep:/pub/gnu/clisp/latest/clisp-2.47.tar.gz and it would be a >>> valid logical pathname and not a network path. >> "It" being prep:clisp? Then, yes, I agree, if prep had been previously >> defined as a logical pathname host. > > no. you are missing the whole point! "prep:clisp" _looks_ like a > logical pathname, but is is actually an _ftp location_. "prep" is an > internet host. when you ftp to it, you get to a certain default > directory, in which you find a file "clisp" which will get you the > latest clisp distrib. What do you mean "ftp to it"? Does (open "prep:clisp" ...) recognize prep as an internet host and open an ftp connection to it? I'm also confused on how an ftp location is related to whether "prep:clisp" is a logical pathname or not. > >>> I find this to be just on of the many problems with the pathname spec >>> (my pet peeve is that the #s(pathname ...) notation is not standard >>> for readable output despite being used in the examples). >>> >> I think it's a given that anyone using namestrings is on shaky >> ground. For any one who cares, he's supposed to manipulate pathname >> objects >> instead of namestrings. > > yes, but the standard does not allow you to save the pathnames to > files in a readable format. Won't #.(make-pathname <args>) work? (Well, it won't if you *read-eval* is NIL.) > > http://clisp.cons.org/impnotes/faq.html#faq-ansi > http://clisp.cons.org/impnotes/faq.html#faq-fine > http://clisp.cons.org/impnotes/ansi.html > Ah, thank you! Ray |
From: Raymond T. <ray...@er...> - 2008-12-22 16:39:04
|
Sam Steingold wrote: > Raymond Toy wrote: >>>>>>> "Raymond" == Raymond Toy <ray...@er...> writes: >> >> Raymond> But "prep:/pub/gnu" clearly can't be a logical pathname >> because it has >> Raymond> illegal characters. >> >> Oops, I'm wrong. "prep:/pub/gnu" isn't illegal. But it is undefined, >> according to CLHS 19.3.1.1.8 if it's being used as a logical pathname >> namestring. > > yes. so prep:clisp could be a symbolic link to to the latest clisp > release prep:/pub/gnu/clisp/latest/clisp-2.47.tar.gz and it would be a > valid logical pathname and not a network path. "It" being prep:clisp? Then, yes, I agree, if prep had been previously defined as a logical pathname host. > I find this to be just on of the many problems with the pathname spec > (my pet peeve is that the #s(pathname ...) notation is not standard > for readable output despite being used in the examples). > I think it's a given that anyone using namestrings is on shaky ground. For any one who cares, he's supposed to manipulate pathname objects instead of namestrings. I agree that readable pathnames should have used something more standardized. CMUCL works around this by use #P(...) when it otherwise can't use the normal #P"..." to get a readable pathname object. (I think this is an ANSI compatible extension.) On a slightly different topic: Clisp has quite a few flags enabling ANSI behavior in various areas. It would be nice if there were some function that would enable all of these flags. For those who would like clisp to be a little more ANSI. :-) Ray |
From: Sam S. <sd...@gn...> - 2008-12-22 16:55:08
|
Raymond Toy wrote: > Sam Steingold wrote: >> yes. so prep:clisp could be a symbolic link to to the latest clisp >> release prep:/pub/gnu/clisp/latest/clisp-2.47.tar.gz and it would be a >> valid logical pathname and not a network path. > "It" being prep:clisp? Then, yes, I agree, if prep had been previously > defined as a logical pathname host. no. you are missing the whole point! "prep:clisp" _looks_ like a logical pathname, but is is actually an _ftp location_. "prep" is an internet host. when you ftp to it, you get to a certain default directory, in which you find a file "clisp" which will get you the latest clisp distrib. >> I find this to be just on of the many problems with the pathname spec >> (my pet peeve is that the #s(pathname ...) notation is not standard >> for readable output despite being used in the examples). >> > I think it's a given that anyone using namestrings is on shaky ground. > For any one who cares, he's supposed to manipulate pathname objects > instead of namestrings. yes, but the standard does not allow you to save the pathnames to files in a readable format. > I agree that readable pathnames should have used something more > standardized. CMUCL works around this by use #P(...) when it otherwise > can't use the normal #P"..." to get a readable pathname object. (I > think this is an ANSI compatible extension.) yes, and clisp writes ''#+clisp #s(pathname ...) #-clisp #p""'' > On a slightly different topic: Clisp has quite a few flags enabling > ANSI behavior in various areas. It would be nice if there were some > function that would enable all of these flags. For those who would like > clisp to be a little more ANSI. :-) http://clisp.cons.org/impnotes/faq.html#faq-ansi http://clisp.cons.org/impnotes/faq.html#faq-fine http://clisp.cons.org/impnotes/ansi.html |
From: Sam S. <sd...@gn...> - 2008-12-18 18:56:29
|
Raymond Toy wrote: >>>>>> "Sam" == Sam Steingold <sd...@gn...> writes: > Sam> http://clisp.cons.org/impnotes/filename-misc.html#parsename > > Is it really confusing about parsing "c:/autoexec.bat", > "home:.clisprc", and "prep:/pub/gnu" according to ANSI rules? what is "c:autoexec.bat"? is it a physical pathname or a logical one? > Well, I guess you'd need to look to see if you have logical hosts > names "c", "home" or "prep". And I guess the parsing would change if > you suddenly defined logical hosts. But people don't really do that > except to play games and screw things up intentionally. :-) > > But "prep:/pub/gnu" clearly can't be a logical pathname because it has > illegal characters. when you type explicit pathnames at the command line by hand, the confusion is minimal - you know what you mean. when the pathname comes from munching a few user variables, reading files and environment &c, the confusion can be huge. |
From: Raymond T. <ray...@er...> - 2008-12-18 19:34:59
|
>>>>> "Sam" == Sam Steingold <sd...@gn...> writes: Sam> Raymond Toy wrote: >>>>>>> "Sam" == Sam Steingold <sd...@gn...> writes: Sam> http://clisp.cons.org/impnotes/filename-misc.html#parsename >> Is it really confusing about parsing "c:/autoexec.bat", >> "home:.clisprc", and "prep:/pub/gnu" according to ANSI rules? Sam> what is "c:autoexec.bat"? Sam> is it a physical pathname or a logical one? As I said, you'd have to see if logical hosts were defined or not. Or you could just (translate-logical-pathname "c:autoexec.bat") and see what comes out. Or use (typep (pathname "c:autoexec.bat") 'logical-pathname), but Clisp's PATHNAME isn't ANSI by default, so that's not very useful. Naemstrings don't live in a vacuum, so you need context (an OS) in this case to figure out what it means anyway. >> Well, I guess you'd need to look to see if you have logical hosts >> names "c", "home" or "prep". And I guess the parsing would change if >> you suddenly defined logical hosts. But people don't really do that >> except to play games and screw things up intentionally. :-) >> But "prep:/pub/gnu" clearly can't be a logical pathname because it >> has >> illegal characters. Sam> when you type explicit pathnames at the command line by hand, the Sam> confusion is minimal - you know what you mean. Sam> when the pathname comes from munching a few user variables, reading Sam> files and environment &c, the confusion can be huge. I guess. I don't do that kind of stuff so I wouldn't know. And I don't run Lisp on windows, so "c:autoexec.bat" is a phyiscal pathname unless I defined the logical host "C". Ray |
From: Sam S. <sd...@gn...> - 2008-12-22 19:10:10
|
Raymond Toy wrote: > What do you mean "ftp to it"? ftp(1) > Does (open "prep:clisp" ...) recognize > prep as an internet host and open an ftp connection to it? it could - given a good standard. > I'm also confused on how an ftp location is related to whether > "prep:clisp" is a logical pathname or not. the notion of logical pathnames was introduced to enable automatic pathname transformations. they were kept "separate" from the physical pathnames with a uniquely recognizable syntax to avoid confusion. the problem is that some perfectly physical pathnames like "prep:emacs" looks like logical pathnames. a better approach, IMO, would have been to have pathnames with just 3 fields: host, directory and name, and have all pathname operations (OPEN, TRUENAME &c) dispatch on host. alas, it is too late now. >> yes, but the standard does not allow you to save the pathnames to >> files in a readable format. > Won't #.(make-pathname <args>) work? (Well, it won't if you *read-eval* > is NIL.) make-pathname does some non-trivial processing. also, it is NOT used by (with-standard-io-syntax (write pathname)). Sam. |
From: Raymond T. <ray...@er...> - 2008-12-22 20:15:23
|
>>>>> "Sam" == Sam Steingold <sd...@gn...> writes: Sam> Raymond Toy wrote: >> What do you mean "ftp to it"? Sam> ftp(1) Yes, I know what ftp means, but you confused me with interpreting the pathname namestring with things outside the scope of pathnames and Common Lisp. >> I'm also confused on how an ftp location is related to whether >> "prep:clisp" is a logical pathname or not. Sam> the notion of logical pathnames was introduced to enable automatic Sam> pathname transformations. they were kept "separate" from the physical Sam> pathnames with a uniquely recognizable syntax to avoid confusion. Sam> the problem is that some perfectly physical pathnames like Sam> "prep:emacs" looks like logical pathnames. Sam> a better approach, IMO, would have been to have pathnames with just 3 Sam> fields: host, directory and name, and have all pathname operations Sam> (OPEN, TRUENAME &c) dispatch on host. Sam> alas, it is too late now. You can parse namestrings however you want. Is there something in the spec that prevents you from doing this already? IIRC, OPEN, TRUENAME, etc., already have to know if the filespec is a logical pathname so that it can be translated to a physical pathname. Hence, it already looks at the host. >>> yes, but the standard does not allow you to save the pathnames to >>> files in a readable format. >> Won't #.(make-pathname <args>) work? (Well, it won't if you *read-eval* >> is NIL.) Sam> make-pathname does some non-trivial processing. Sam> also, it is NOT used by (with-standard-io-syntax (write pathname)). One can argue that #P"..." is the readable format. That #P"..." can't represent, readably, all of the possible pathname objects is a different issue. Since parsing of namestrings is completely implementation specific, you can create your own notation for this. Might not go over very well with users if the namestrings don't match expectations for the actual file system. Ray |