Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)

[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>

    ... don't you need functions like Symbolics' DIRECTORY-PATHNAME-AS-FILE and
    PATHNAME-AS-DIRECTORY?  The conversion between the name of a directory
    and the directory component of a file inferior to that directory is
    system-dependent, for example TOPS-20 appends a type field and Unix does
    not.  Also in some systems the root directory has a name and in others
    it doesn't.  Of course these functions signal an error in
    non-hierarchical file systems.  Should there be a separate proposal for
    these? ...

I guess it's enough related to this topic that it could piggy back.
Certainly these functions made no sense prior to this proposal and
now they are suddenly important, so I'll see about putting them in on
next pass.

    ... Is :OUT a typo for :BACK? ...

Yeah. Sloppy editing. Sorry.

    Also I don't understand what your proposed semantic/syntactic
    distinction ...

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.

Genera is syntactic in that it doesn't probe when processing :UP.
That means that MERGE-PATHNAMES on
 (:ABSOLUTE "X" "Y" "Z")
and
 (:RELATIVE :UP "Q")
returns
 (:ABSOLUTE "X" "Y" "Q")
rather than
 (:ABSOLUTE "X" "Y" "Z" :UP "Q")
If you were going to contract out the :UP, you'd need to probe the
file system to make sure 
 (:ABSOLUTE "A" "B" "Q")
wasn't more correct than
 (:ABSOLUTE "X" "Y" "Q")
so I think Genera has a bug.

I think this because if I do:
 cd /m/n/o
 cd ../q
on Unix I get one place, but in Genera if I visit a file in the
editor named
 /m/n/o/x.lisp
and then I type c-X c-F and when prompted for a filename I type
 ../q/x.lisp
I end up with
 /m/n/o/q/x.lisp
rather than the x.lisp in the directory that Unix itself would have
plopped me in if I'd used the cd commands above.

If you disagree, please reply to me privately so we can avoid
further confusion, quickly iron it out offline, and then report a
joint answer (and rationale) to everyone else once we've achieved
consensus.

    I also don't think :UP and :BACK are meaningful anywhere except immediately
    after :RELATIVE, although I have to concede that Unix disagrees with me
    and therefore Symbolics Genera's Unix pathname support also disagrees
    with me.

When I previously raised this topic, there were a pile of messages on
exactly this subject. My putting these into the proposal was an attempt
to address those topics. Even if I took these out, the current proposal
offers the flexibility that implementations could offer them without being
in violation of the spec. On the other hand, if people -are- going to offer
them, we might as well agree on common names if it's possible to do so.

    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? Our (Symbolics) pathname system doesn't
permit embedded "<", but the error message suggests that this is only
because there's no obvious interpretation. We could define it to mean
:BACK rather than :UP, so that syntactic merges could be done and
unique pathnames would always be generated.

    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.

	Current Practice:

	   - Genera represents Unix ".." as :UP, but deals with :UP 
	     syntactically, not semantically.

    After you straighten out the definition of syntactic and semantic, check
    whether this statement is true.  (I'm always irked by proposals where
    the current practice section is wrong, because someone wrote an original
    proposal where the current practice section was right, then the group
    changed the proposal all around but didn't update the current practice
    section).

I'll double-check when I've made the next version.

	Discussion:

	  This issue used to address the issue of relative pathnames (pathnames
	  relative to some default which is separately maintained). Pitman removed
	  this issue for now in order to simplify things. He feels the issue should
	  be resubmitted under separate cover so that it can be discussed separately.

    It seems to me that this fully addresses relative pathnames already.  The
    discussion of :UP and :BACK (if freed of typos) seems specific enough that
    even though this proposal doesn't explicitly propose what MERGE-PATHNAMES
    does with relative pathnames, I think there is only one thing that it could
    do that would be consistent.  A pathname with a :RELATIVE directory is
    not very different from a pathname with a NIL directory; in either case
    you have to merge with a default to find the real directory to use; thus
    I don't think there are any other new issues with relative pathnames.

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?