[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
- To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 29 Dec 88 16:05 EST
- Cc: CL-Cleanup@SAIL.STANFORD.EDU
- In-reply-to: <881229145413.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Thu, 29 Dec 88 14:54 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Date: Thu, 29 Dec 88 13:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Also I don't understand what your proposed semantic/syntactic
Semantic means you have to probe the file system. Syntactic means
looking at the file names themselves is enough. Maybe I screwed up
the presentation. I'll double-check.
OK, I understand, and you did screw up the presentation.
But if they were only allowed immediately after :RELATIVE I
don't think you would need two of them.
I claim my example above refutes this.
I also don't think that
MERGE-PATHNAMES should ever look at what files/directories actually
exist in the file system,
If you permit :UP in absolute pathnames, you don't have to look in the
file system. You just get some funny names. Most file systems that
have this feature permit such funny names, though. eg, /foo/../bar/x
is valid in Unix, I understand. If memory serves me, Multics permits
>foo>bar>baz<x>y in Multics, no?
No. Although that's from memory: there are few Multices left, I don't
have an account of any of them, and my manuals are in the attic at home.
I think you got syntactic and semantic mixed up again. I think you're
saying that MERGE-PATHNAMES of a relative directory against an absolute
directory will remove :UP, since that's purely syntactic, but will leave
:BACK in the middle of the merged directory, since resolving :BACK
"semantically" would require accessing the file system, which
MERGE-PATHNAMES doesn't do. Okay.
These names are extremely confusing, obviously. Can anyone think
of better ones than :UP and :BACK?
Our (Symbolics) pathname system doesn't
permit embedded "<", but the error message suggests that this is only
because there's no obvious interpretation.
The error message I get doesn't suggest anything, it's just "Embedded <?".
We could define it to mean
:BACK rather than :UP, so that syntactic merges could be done and
unique pathnames would always be generated.
I don't understand this sentence. Say it again after we all agree on
which one is :UP and which one is :BACK.
which makes me opposed to the existence
of the one that you have called syntactic.
In any case, I'm sympathetic to your desire to not look in the file
system. I just think that if a file system designer has made a
decision that forces you to look in the file system to get the right
answer, I don't know what we the CL designers can do to alter that.
The same issue comes up for logical devices and as Sandra has reminded
us, we've not done a particularly good job of papering over that real
externally-induced issue either.
Is this really something we need, or will TRUENAME do the job?
TRUENAME and OPEN would, presumably, not return pathnames with :UP
references (except maybe in pathological situations which they tell
me you can make in Unix if you try hard enough where the only way to
get to a directory is to go down first and then dig upward.)
I think we should only have :UP and not :BACK.
Nothing forces a file system to have both. The question is whether
there are some file systems that have one set of semantics and others
which have the other. If so, then two tokens are needed. In the discussion
leading up to this, people asserted (and I took them at their word) that
there were such competing semantics.
I don't know enough about the weird file systems out there to dispute this.
Well, there was the whole treatment of :UP. I hadn't really meant for this
proposal to specify that treatment so much as to identify a common representation
so we'd be a little less divergent in the areas we hadn't really specified.
Does anyone think I should add a disclaimer in the proposal body similar to the
one for :OLDEST, :INSTALLED, etc in pathname versions in CLtL that says that
although these are semi-standard names, there is no attached semantics?
Yes, I think :UP and :OLDEST have the same status, but no I don't agree
that that status is that they have no semantics. I agree with what CLtL
page 412 actually says, which is that either an implementation doesn't
support these keywords or if it does support them they have prescribed