Fwd: Re: [Openmcl-devel] delete-file and directories
gk1 at four-four.com
Mon Mar 14 13:11:35 PST 2005
Thanks for the replies, Gary and all.
I also agree that we should have a DELETE-DIRECTORY, and I think your point about the fact that we have only a few filesystems in widespread use is worth considering.
Practically speaking, it has been very convenient for me as programmer who works extensively with filesystems to have one function, DELETE-FILE (in MCL) to delete a pathname passed to it, whether file or directory. Perhaps we should have a pathspec-encompassing function, DELETE-PATH, which would do the work. Maybe someday we won't have filesystems (on disk drives, anyway) as we know them, though we'll probably have a (node-based?) PATH to some information, and DELETE-FILE was a bad name choice to begin with.
COPY-FILE: On OSX, should COPY-FILE call "CpMac" or something similar, instead of "cp?" I'm guessing most of us using OSX still have files with resource forks, and will likely have them for a while. How do we detect and copy resource forks in OpenMCL, without making an objc call?
>On Sat, 12 Mar 2005, Gary Byers wrote:
>I also agree that the spec leaves a lot intentionally unsaid; it
>says that DELETE-FILE deletes the -file- specified by its filespec
>arg; the glossary entry for "file" says only that it's a named
>entity that lives in the filesystem and whose nature is implementation-
>dependent. (So, it's not necessarily incorrect for an implementation
>to interpret "file" to include "directories", and may be very reasonable
>to do so in at least some hypothetical file systems.)
>(defun DELETE-DIRECTORY (pathname &optional (recursively nil))
>e.g., it seems that it'd be desirable to maintain this distinction.
>(There might be other plausible options: if some of the directory's
>contents can't be deleted because of permission issues, how should
>the function behave? Etc.)
>I could sort of believe that existing lisps -could- standardize on
>some sort of de facto standard DELETE-DIRECTORY function, at least
>partly because there are really only 2 or maybe 3 filesytems in
>widespread use today and they all offer similar semantics.
More information about the Openmcl-devel