[Openmcl-devel] Directory and symlinks

[Waldek Hebisch]

> 
> If only there was a language specification that gave us at least some
> guidelines as to what to expect, we wouldn't have to all announce what
> our intuition leads us to expect (for DIRECTORY or a few hundred other
> things.)
> 
> Oh wait ... there is such a spec.  What it says about DIRECTORY's behavior
> uses terms like "matching" and "present in the file system" without fully
> defining those terms.
> 
> CCL, SBCL, AllegroCL, and LispWorks (at least the versions that I have)
> interpret those terms differently than you apparently do.  If you think
> that that interpretation of what the spec actually says is wrong, I'd
> be interested in hearing why.  (Substantially more intetrested than I
> am in hearing a bunch of people say "I expect ...".)  I don't always
> expect SORT to destructively modify its argument, but if I read the spec
> I should expect that; my expectations (except as they pertain to the spec)
> aren't too interesting.
>
> If the spec had said (of DIRECTORY) that it determines the set of files
> whose TRUENAMEs match, then there'd be a strong basis for your expectation.
> What it does say strongly suggests that TRUENAME is used in producing the
> result from a set of matching files but not in determining the elements
> of that set.  (/usr/local/src/ccl isn't "present in the filesystem" in
> my home directory; a file whose TRUENAME is /usr/local/src/ccl is.)
>

Garry, of course the question is which files have names matching
pathspec.  I was unable to find in HyperSpec any definition
saying when file name matches given pathspec -- if you found
at least some partial definition that could invalidate what
I write below.  Given no definition of "file name matching pathspec"
implementation can do anything and current behaviour of CCL is
legal.  

The pathspec is question is a namestring.  About them we
have:

 In general, the syntax of namestrings involves the use of
 implementation-defined conventions, usually those customary
 for the file system in which the named file resides. 

If CCL strictly followed Linux conventions, then probably
"ccl/*.image" would not match at all (at least bash-4.1.5
wildcard expansion does not find it).  But once CCL decided
to follow symlinks for purpose of wildcard matching, it
seem reasonable to follow tradition of doing match
componentwise.  And componentwise match means that
name matching "ccl/*.image" matches also "*/*.image"

Of course implementation-defined means that you can ignore
any such expectations...

-- 
                              Waldek Hebisch
hebisch at math.uni.wroc.pl