From: Eric Moss
Subject: error in lispworks' #'directory or in my head???
Date:
Message-ID: <3C281272.9F322230@alltel.net>
Hi all,
In a directory with the following files:
/foo/Makefile
/foo/Makefile.preamble
/foo/Makefile.postamble
(directory "/foo/Makefile") and (directory (pathname "/foo/Makefile"))
both return:
(#P"/foo/Makefile.preamble" #P"/foo/Makefile"
#P"/foo/Makefile.postamble")
as though the pathspec were wild. However,
(wild-pathname-p (pathname "/foo/Makefile")) => nil
and the hyperspec for #'directory says that if a pathspec is not wild,
the resulting list will contain either zero or one elements.
Is this an error in the lispworks implementation?
Thanks,
Eric
PS I was using this to decide if a filename is a file or a directory.
The idea was that if #'directory returns the same pathspec, using
#'equal, as was passed to it, the pathspec is a file. If not (ie,
#'directory returns nil or other filespecs) then the pathspec must have
been a directory.
Python lets me check file-ness or directory-ness or link-ness. Is there
a portable way in lisp?
On Mon, 24 Dec 2001 23:45:22 -0600, Eric Moss <········@alltel.net>
wrote:
>Hi all,
>
>In a directory with the following files:
>
> /foo/Makefile
> /foo/Makefile.preamble
> /foo/Makefile.postamble
>
>(directory "/foo/Makefile") and (directory (pathname "/foo/Makefile"))
>both return:
>
> (#P"/foo/Makefile.preamble" #P"/foo/Makefile"
>#P"/foo/Makefile.postamble")
>
>as though the pathspec were wild. However,
>
>(wild-pathname-p (pathname "/foo/Makefile")) => nil
>
>
>and the hyperspec for #'directory says that if a pathspec is not wild,
>the resulting list will contain either zero or one elements.
>
>
>Is this an error in the lispworks implementation?
>
>
I'd say it is ambiguous whether a pathname that is interpreted as wild
within the context of DIRECTORY must satisfy wild-pathname-p. I base
this claim on the 2nd definition of 'wild' in the hyperspec:
2. (of a pathname) a structured representation of a name which might
``match'' any of possibly several pathnames, and which can therefore
be used to refer to the aggregate of the files named by those
pathnames. The set of wild pathnames includes, but is not restricted
to, pathnames which have a component which is :wild, or which have
a directory component which contains :wild or :wild-inferors.
Note the use of 'might', 'match' in quotes, and 'but is not restricted
to'.
I would say that in general, it would be a practical error to rely on
the behavior of DIRECTORY across implementations or OS's in all but
the clearest and most obvious cases, and even then I would test to
make sure I was getting the behavior I thought I should be getting.
>
>PS I was using this to decide if a filename is a file or a directory.
>The idea was that if #'directory returns the same pathspec, using
>#'equal, as was passed to it, the pathspec is a file. If not (ie,
>#'directory returns nil or other filespecs) then the pathspec must have
>been a directory.
>
>Python lets me check file-ness or directory-ness or link-ness. Is there
>a portable way in lisp?
Given the behavior you say is true of Lispworks, no immediately
obvious way comes to mind.
From: Erik Naggum
Subject: Re: error in lispworks' #'directory or in my head???
Date:
Message-ID: <3218349950634232@naggum.net>
* Eric Moss <········@alltel.net>
| Python lets me check file-ness or directory-ness or link-ness. Is there
| a portable way in lisp?
Are fileness, directoryness, and linkness portable concepts?
I would expect such things to be part of the operating system interface.
Since Common Lisp is more portable than Python, and has a far longer
history, the operating systems it has to be portable across are far more
numerous.
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
Erik Naggum <····@naggum.net> writes:
> * Eric Moss <········@alltel.net>
> | Python lets me check file-ness or directory-ness or link-ness. Is there
> | a portable way in lisp?
>
> Are fileness, directoryness, and linkness portable concepts?
>
> I would expect such things to be part of the operating system interface.
> Since Common Lisp is more portable than Python, and has a far longer
> history, the operating systems it has to be portable across are far more
> numerous.
Certainly there are file systems whose directories do not manifest as
files and so there is nothing obvious to ask directory-p of, and, by
implication, file-p is less than interesting in that case (mostly returning
true a lot). As to linkness, symbolic links where they exist are worth
checking for, but hard links are something you can't detect. And
file-system-level search lists can behave in ways like file links but
differently. Consider Tops-20 ability to name a "device" as really a
search list... There were OS/file systems we encountered in the design
that had no directory at all, btw. There is almost no commonality to all
file systems. Of course, there is some virtue in not designing for some
bad OS's. But I wouldn't say that's the same as designing for DOS/Unix only.
From: Jean-Fran=?ISO-8859-1?B?5w==?=ois Brouillet
Subject: Re: error in lispworks' #'directory or in my head???
Date:
Message-ID: <B853DC86.2EA1%verec@mac.com>
> Kent M Pitman <······@world.std.com> wrote:
Certainly there are file systems whose directories do not manifest as
files and so there is nothing obvious to ask directory-p of, and, by
implication, file-p is less than interesting in that case (mostly
returning true a lot). As to linkness, symbolic links where they exist
are worth checking for, but hard links are something you can't detect.
And file-system-level search lists can behave in ways like file links but
differently. Consider Tops-20 ability to name a "device" as really a
search list... There were OS/file systems we encountered in the design
that had no directory at all, btw. There is almost no commonality to all
file systems. Of course, there is some virtue in not designing for some
bad OS's. But I wouldn't say that's the same as designing for DOS/Unix
only.
I'm not sure how this invalidates the "least common denominator approach"
or even whether this _validates_ the very notion of CL's pathname/CL's
directory.
Not that I'm arguing about trying to change the way CL was designed (a bit
late, for that :) but having a so-called _Common_ Lisp standard, not having
a common way of dealing with files/directories is a bit odd at best.
Consider the following cases:
o platform does not support a file-system at all
Problem solved. You can't write portable code that uses files/directory
for that platform anyway. So Common Lisp or not, your application can't
be ported. period.
o platfom does support a hierarchical file system.
A CL call ought to return the list of mounted volumes, as starting
points, from where further "downwards" directory scanning should
be possible.
o platfom does support a flat file system.
Same case as above, except that you have only one volume/directory
to worry about
I don't have the time or inclination to flesh out a consistent proposal,
but this is a _solved problem_ (I know of a least one environment which
solved this issue eons agon (OK: 6 years or so ago) Kaleida's ScriptX
-- whether ScriptX is dead is irrelevant --)
And resorting to arguments about TOPS, SPOT (or is it STOP that nonsense?-)
pre-dating computing common era as show-stoppers when navigating a
hierarchical structure is a known problem with myriads of known solutions
seems to be a bit over the top.
For all the nice things I'd have to say about Common Lisp, I'd rather
keep silent about this obvious shortcoming; but that's just me ;)
--
Jean-Francois Brouillet
From: Christopher Stacy
Subject: Re: error in lispworks' #'directory or in my head???
Date:
Message-ID: <uvgepg2a9.fsf@spacy.Boston.MA.US>
>>>>> On Sat, 29 Dec 2001 20:48:06 +0000, Jean-Fran=?ISO-8859-1?B?5w==?=ois Brouillet ("JF") writes:
JF> Not that I'm arguing about trying to change the way CL was designed (a bit
JF> late, for that :) but having a so-called _Common_ Lisp standard, not having
JF> a common way of dealing with files/directories is a bit odd at best.
It is a defficiency of Common Lisp, and was felt by some people at the
time to be so. However, doing a good portable general pathname system
turns out to be really hairy. Symbolics Common Lisp had all this fully
worked out and winning, but my understanding is that it seemed to the
majority of the committee members that it was too complex, and perhaps
therefore too experimental, to be included at the time.
So, now you have to somehow build up your own from the incomplete
pieces that did make it into Common Lisp.
Erik Naggum <····@naggum.net> writes:
> * Eric Moss <········@alltel.net>
> | Python lets me check file-ness or directory-ness or link-ness. Is there
> | a portable way in lisp?
>
> Are fileness, directoryness, and linkness portable concepts?
>
> I would expect such things to be part of the operating system interface.
> Since Common Lisp is more portable than Python, and has a far longer
> history, the operating systems it has to be portable across are far more
> numerous.
>
Sure. But considering multiple LISP implementations on a same OS
it would be desireable that they converge towards a common interface
to common services.
Since and nowadays, there seems to be only two commercially active families
of mainstream OS, Windows and UNIX variants (MacOS having migrated into the
latter), and all of them share a lot of common concepts, these two interfaces
could also share a lot.
Other living LISPs seem to be embedded lisps and LISP machines,
that are sui generis anyway. I doubt anyone is writing LISP code for
TOPS/20, VMS, or some IBM big iron OS. So there seems to be little point
in refusing to seek some kind of standard for LISP access to filesystems
due to some obsolete systems.
In any case, it could be interesting to see whether the vendor-specific
interfaces to the filesystem in mainstream OSes could be unified,
or if not, why not.
[ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[ TUNES project for a Free Reflective Computing System | http://tunes.org ]
Past is important exactly in as much as it affects the future and as such only.
On 26 Dec 2001 21:41:42 +0100, Francois-Rene Rideau
<···········@tunes.org> wrote:
>Other living LISPs seem to be embedded lisps and LISP machines,
>that are sui generis anyway. I doubt anyone is writing LISP code for
>TOPS/20, VMS, or some IBM big iron OS. So there seems to be little point
>in refusing to seek some kind of standard for LISP access to filesystems
>due to some obsolete systems.
Similar arguments apply to the failure to provide anything approaching
a common approach to gui issues.
It seems to be a matter of mind-set than anything else.