[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


    Date: Mon, 23 Jan 89 17:40:47 -0500
    From: andrew@linc.cis.upenn.edu

    Ok, I see your point but the scheme doesn't work.  Suppose I have
    a defsystem form and I have a short-name attribute "foo". If this
    system is stored on a unix host with a physical default pathname,
    the system will try to look for files of the form
    FOO.system-dir, etc.., instead of foo.system-dir.  Thats not at
    all what I expect, nor what is stored on the unix machine.

I can understand it not being what you expect, but how can it not be
what is stored?  Since SCT creates the FOO.system-dir file itself, it
should consistently look for it with that name.

When SCT is used along with logical pathnames, the right thing happens.
SCT will create the pathname LOGICAL-HOST:DIR;PATCH;foo.SYSTEM-DIR.  The
logical pathname facility will uppercase this, resulting in
FOO.SYSTEM-DIR, and then the translation to a Unix pathname will
generate foo.system-dir, as you expect.

And if you make the short name be "FOO", it works everywhere.

      This problem manifests itself in many different forms, in
    places where none of my code is responsible for sending parsing messages
    to the pathname. Why shouldn't LOWER-CASE-PREFERRED-MIXIN do exactly
    what it says?

It does.  It says that the preferred case is lowercase, so when the
pathname software is asked to create default-case pathnames they are
lowercase.  But the converse is also true: when the pathname software is
asked to create opposite-of-default-case pathnames (by using lowercase
with an operation that expects its argument in interchange case), it
creates uppercase names.

This is the only way to get cross-OS pathname translation to work
properly.  I remember the days before Symbolics worked this scheme out
-- it was a mass of heuristics and kludges that frequently resulted in
TOPS-20 file names that required special quoting so that they could be

You still haven't described your changes in detail, but it sounds like
your scheme only works when translating default-case pathnames.  The
point of the Symbolics scheme is that if you are translating a lowercase
TOPS-20 pathname component to a Unix pathname you should get an
uppercase result, because non-default-case components stay that way when
they are copied to a pathname on a different OS (although you DO lose
information when the component is copied to a case-insensitive host such
as LMFS or ITS).