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?
>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.
* Eric Moss <ericm...@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 <e...@naggum.net> writes: > * Eric Moss <ericm...@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.
Erik Naggum <e...@naggum.net> writes: > * Eric Moss <ericm...@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
<fare+NOS...@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.
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 ;)
>>>>> 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.
