I can't find anywhere in the spec where it's really clear that a
truename must be an absolute path. It would seem to me strange for a
truename to be relative, to say the least, but perhaps there are cases
I haven't thought of?
Are there cases where truenames can be relative?
Thanks
--tim
(By `relative' I mean (eq (first (pathname-directory x)) ':relative))
··········@tfeb.org (Tim Bradshaw) writes:
> I can't find anywhere in the spec where it's really clear that a
> truename must be an absolute path. It would seem to me strange for a
> truename to be relative, to say the least, but perhaps there are cases
> I haven't thought of?
>
> Are there cases where truenames can be relative?
I would say no, going from CLHS 20.1.3:
"... most file systems have a convention for generating a canonical
filename in such situations. Such a canonical filename (or the
pathname representing such a filename) is called a truename."
I don't see how you can have a canonical pathname have :directory
'(:relative ...), as then the actual pathname would depend on the
value of *default-pathname-defaults*. Of course, I could be missing
something too...
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Christophe Rhodes <·····@cam.ac.uk> writes:
> ··········@tfeb.org (Tim Bradshaw) writes:
>
> > I can't find anywhere in the spec where it's really clear that a
> > truename must be an absolute path. It would seem to me strange for a
> > truename to be relative, to say the least, but perhaps there are cases
> > I haven't thought of?
> >
> > Are there cases where truenames can be relative?
>
> I would say no, going from CLHS 20.1.3:
>
> "... most file systems have a convention for generating a canonical
> filename in such situations. Such a canonical filename (or the
> pathname representing such a filename) is called a truename."
>
> I don't see how you can have a canonical pathname have :directory
> '(:relative ...), as then the actual pathname would depend on the
> value of *default-pathname-defaults*. Of course, I could be missing
> something too...
I agree. To be canonical is to be the uniquely determined representative.
Relative names are not uniquely determined--they are (directory) context
dependent.
[Apologies for the belated followup...]
Kent M Pitman <······@world.std.com> wrote:
+---------------
| Christophe Rhodes <·····@cam.ac.uk> writes:
| > > Are there cases where truenames can be relative?
| >
| > I would say no, going from CLHS 20.1.3:
| > "... most file systems have a convention for generating a canonical
| > filename in such situations. Such a canonical filename (or the
| > pathname representing such a filename) is called a truename."
...
| I agree. To be canonical is to be the uniquely determined representative.
+---------------
But then CL truenames do not meet your criterion for being "canonical".
As CLHS 20.1.3 points out:
"The truename for a file is often, but not necessarily, unique
for each file. For instance, a Unix file with multiple hard links
could have several truenames."
I suspect that's why the earlier CHLS text (quoted by Rhodes, above)
said "*a* canonical filename", rather than "*the* canonical filename"...
-Rob
-----
Rob Warnock, 30-3-510 <····@sgi.com>
SGI Network Engineering <http://www.meer.net/~rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: ·········@sgi.com and ········@sgi.com aren't for humans ]
····@rigden.engr.sgi.com (Rob Warnock) writes:
> [Apologies for the belated followup...]
>
> Kent M Pitman <······@world.std.com> wrote:
> +---------------
> | Christophe Rhodes <·····@cam.ac.uk> writes:
> | > > Are there cases where truenames can be relative?
> | >
> | > I would say no, going from CLHS 20.1.3:
> | > "... most file systems have a convention for generating a canonical
> | > filename in such situations. Such a canonical filename (or the
> | > pathname representing such a filename) is called a truename."
> ...
> | I agree. To be canonical is to be the uniquely determined representative.
> +---------------
>
> But then CL truenames do not meet your criterion for being "canonical".
> As CLHS 20.1.3 points out:
>
> "The truename for a file is often, but not necessarily, unique
> for each file. For instance, a Unix file with multiple hard links
> could have several truenames."
>
> I suspect that's why the earlier CHLS text (quoted by Rhodes, above)
> said "*a* canonical filename", rather than "*the* canonical filename"...
Yes. The key to understanding this is to understand that the reason we
allowed it to be "not necessarily" was because we couldn't force an
operating system to obey the model we wanted. It was NOT to allow
implementations to vary when operating systems do have such a model.
Most uses for truename are to expand device aliaes (a Tops-20 logical
device MYFILES: might turn into PS:) or to fill in versions (not
relevant for Unix and DOS, but relevant to Lisp Machines, ISO file
systems, ITS, VAX VMS, and Tops-20). One would *hope* that at least
an implementation would remove the :back's from a filename directory
(though there's more question about what to do with :up ... in
well-formed file systems it's meaningful to remove those as well, but
in ill-formed file systems one sometimes can't). And usually truename
would go through symbolic links, though (as noted above) unix hard links
are more problematic.