Hi,
In CMUCL there is a function called DEFAULT-DIRECTORY. This function
doesn't
seem to exist in Allegro,Harlequin for windows. Is this function ANSI
or is
there a corresponding ANSI version of it?
Thanks,
Tunc
In article <·················@EECS.Berkeley.Edu>,
H. Tunc Simsek <······@EECS.Berkeley.Edu> wrote:
>In CMUCL there is a function called DEFAULT-DIRECTORY. This function
>doesn't
>seem to exist in Allegro,Harlequin for windows. Is this function ANSI
>or is
>there a corresponding ANSI version of it?
There is no direct ANSI CL equivalent, because at the time the standard
was developed, not all OSes supported the concept of default or current
directory, nor did they all have hierarchical tree-structured
directories. Now most of them have both. This is one place where the
standard could be improved (though I'm not going to agitate for this
particular change -- calm down, Kent! :-).
The variable *DEFAULT-PATHNAME-DEFAULTS* can be made to provide this
functionality. The value should be a pathname with the name, type, and
version slots set to NIL, I think.
Allegro has (EXCL:CURRENT-DIRECTORY), I forget what the Harlequin and
Liquid equivalents are.
-- Chuck
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please) ········@home.com (MIME enabled)
Lisp bigot, mountain biker, car nut, sometime guitarist and photographer
The addresses above are real. All spammers will be reported to their ISPs.
Suppose I have a pathname (e.g. #p"/usr/local/bin/")
How can I check whether it is a directory? This function
works in CMUCL but not in anything else:
(defun pathname-directory-p (path)
(if (pathname-name path)
nil
t))
The idea is to check that PATH does not name a file.
what I really want to do is get a list of all subdirectories:
(defun mapappend (fun &rest args)
(if (some #'null args)
()
(append (apply fun (mapcar #'car args))
(apply #'mapappend fun (mapcar #'cdr args)))))
(defun load-system-sub-directories (path)
(let* ((current-directory path)
(sub-directories (remove-if-not #'pathname-directory-p
(directory current-directory))))
;; (cons current-directory
;; (mapcar #'load-system-sub-directories sub-directories))))
;; This gives you a list and not a tree
`(,current-directory
,@(mapappend #'load-system-sub-directories sub-directories))))
What would be a way of writing PATHNAME-DIRECTORY-P so that this
code works in Allegro/Harlequin and CMUCL?
Chuck Fry wrote:
>
> In article <·················@EECS.Berkeley.Edu>,
> H. Tunc Simsek <······@EECS.Berkeley.Edu> wrote:
> >In CMUCL there is a function called DEFAULT-DIRECTORY. This function
> >doesn't
> >seem to exist in Allegro,Harlequin for windows. Is this function ANSI
> >or is
> >there a corresponding ANSI version of it?
>
> There is no direct ANSI CL equivalent, because at the time the standard
> was developed, not all OSes supported the concept of default or current
> directory, nor did they all have hierarchical tree-structured
> directories. Now most of them have both. This is one place where the
> standard could be improved (though I'm not going to agitate for this
> particular change -- calm down, Kent! :-).
>
> The variable *DEFAULT-PATHNAME-DEFAULTS* can be made to provide this
> functionality. The value should be a pathname with the name, type, and
> version slots set to NIL, I think.
>
> Allegro has (EXCL:CURRENT-DIRECTORY), I forget what the Harlequin and
> Liquid equivalents are.
>
> -- Chuck
> --
> Chuck Fry -- Jack of all trades, master of none
> ······@chucko.com (text only please) ········@home.com (MIME enabled)
> Lisp bigot, mountain biker, car nut, sometime guitarist and photographer
> The addresses above are real. All spammers will be reported to their ISPs.
H. Tunc Simsek <······@EECS.Berkeley.Edu> wrote in message
······················@EECS.Berkeley.Edu...
> Suppose I have a pathname (e.g. #p"/usr/local/bin/")
>
> How can I check whether it is a directory? This function
> works in CMUCL but not in anything else:
>
>
> (defun pathname-directory-p (path)
> (if (pathname-name path)
> nil
> t))
>...
> What would be a way of writing PATHNAME-DIRECTORY-P so that this
> code works in Allegro/Harlequin and CMUCL?
In LispWorks there is a lw:file-directory-p function
Marc Battyani
"H. Tunc Simsek" <······@EECS.Berkeley.Edu> writes:
> Suppose I have a pathname (e.g. #p"/usr/local/bin/")
>
> How can I check whether it is a directory? This function works in
> CMUCL but not in anything else:
There is no 100% solution if you are looking for 100% portability. I,
in particular, used to over-concern myself with pathnames portability
(if you do some dejanews searching...). Anyways:
In Allegro CL: FILE-DIRECTORY-P
In LispWorks: FILE-DIRECTORY-P
In MCL [IIRC]: DIRECTORYP
In CMU CL: ??? (write your own)
In CLISP: ???, but has PROBE-DIRECTORY for slightly different effect
Why does your application need to determine if a path is a directory
or not? Lisp is a bad choice for Unix scripting, if that's what you
are trying to do.
In general, you should only make sure your pathname stuff works with
whatever Lisp you are actual using, and then port on a case-by-case
basis to other Lisps as the need arises. This will save you a lot of
time, since Lisp-vendor conformance to ANSI CL pathname standards is
not unlike Microsoft/Netscape browser conformance to W3C standards...
and it takes a lot less time to make your JavaScript work with
Netscape first, and then Explorer, instead of conforming to the
standard and then having to make your standards-conformant JavaScript
work with both browsers....
But in the vendors' defense, the standard leaves out critical
functionality you need, without giving you the required primitives to
implement this functionality, and is very vague on many issues.
Christopher
"Christopher R. Barry" wrote:
>
> "H. Tunc Simsek" <······@EECS.Berkeley.Edu> writes:
>
> > Suppose I have a pathname (e.g. #p"/usr/local/bin/")
> >
> > How can I check whether it is a directory? This function works in
> > CMUCL but not in anything else:
>
> There is no 100% solution if you are looking for 100% portability. I,
> in particular, used to over-concern myself with pathnames portability
> (if you do some dejanews searching...). Anyways:
>
> In Allegro CL: FILE-DIRECTORY-P
> In LispWorks: FILE-DIRECTORY-P
> In MCL [IIRC]: DIRECTORYP
> In CMU CL: ??? (write your own)
> In CLISP: ???, but has PROBE-DIRECTORY for slightly different effect
>
> Why does your application need to determine if a path is a directory
> or not? Lisp is a bad choice for Unix scripting, if that's what you
> are trying to do.
>
No, I'm not at all interested in Unix scripting. I'm just trying to
discover a convenient way to set up my system so that I can port it
to at least a few lisp platforms.
The main idea is a load.lisp file that traverses all the sub-directories
of the project and defines all the systems that are described in
system.lisp
(which presumably contains some DEFSYSTEM forms)
files in the subdirectories. It doesn't actually load any of the
systems
but prints them out and gives you the option of loading any of them.
Also, the system.lisp files may contain DEFLOGICALPATH forms that
allow load.lisp to generate logical-paths for those sub-directories
that contain them.
> In general, you should only make sure your pathname stuff works with
> whatever Lisp you are actual using, and then port on a case-by-case
> basis to other Lisps as the need arises. This will save you a lot of
> time, since Lisp-vendor conformance to ANSI CL pathname standards is
> not unlike Microsoft/Netscape browser conformance to W3C standards...
> and it takes a lot less time to make your JavaScript work with
> Netscape first, and then Explorer, instead of conforming to the
> standard and then having to make your standards-conformant JavaScript
> work with both browsers....
>
> But in the vendors' defense, the standard leaves out critical
> functionality you need, without giving you the required primitives to
> implement this functionality, and is very vague on many issues.
>
Sure, but I think some function will become standard if it is used in
an important project and turns out to be useful. This means that
adhering strictly to the ANSI standard is not always the wisest thing
to do, simply for the reasons you stated.
> Christopher
Other people have commented on the various implementation-specific tools
available. In addition, remember that the function DIRECTORY is supposed
to return a list of files matching some pathname spec (in which some
implementations allow various forms of wildcards). You should be able
to use this to devise a portable, if not very efficient, test.
My personal view is that whether or not it was intended to, the spec
does spell some things out that, to me, require the truenames of
directories to appear in some cannonicalized form such as having the
name, type and version be :unspecified.
I don't think ill of implementations that, for historical reasons,
haven't seen things this way, but I do think it would be nice if
everybody changed to this.
Here's the section from the Eclipse documentation
(http://www.elwood.com/eclipse/path.htm#truenames) that explains what
how we view it:
------------
As defined by ANSI, a truename is a canonicalized pathname in which
wildcards and mnemonic version numbers have
been resolved, logical host translations have been resolved, and, in
general, multiple ways of referring to the same file in
the file system have been resolved to the most canonical form.
There are two Eclipse-specific aspects of this last issue that are of
note:
1.In some situations, some file systems, such as Unix, allow
namestrings that
refer to directories to be specified with
or without the trailing directory separator (eg. "/dir/subdir" or
"/dir/subdir/"). In other words, something that
looks like a filename might refer to a file or to a directory.
In Eclipse, the truename of a directory is always canonicalized
such that the
namestring prints as a directory (eg.
"/dir/subdir/"), and the pathname-name, pathname-type and
pathname-version
are all :UNSPECIFIC.
2.Some file systems allow files to be symbolically linked to other
files or
directories. In general, Eclipse truenames
resolve such links to their ultimate file or directory
destination. However,
DIRECTORY allows the programmer to specify
whether such symbolic links are followed once, completely, or not
at all.
------
If this were always done, then PROBE-FILE, which returns a truename,
could always be used. Of course, I admit that doing this and then
laboriously testing the pathname-name, -type, and -version would be
exactly the type of thing to be abstracted into a function, and if one
is going to create a directory-p function anyway, then there's no reason
to not have it go off and do the implementation-specific thing, instead
of requiring all implementations to support this :unspecific stuff.
On the other hand, I would have more concern over changing the spec to
require the presence of a common DIRECTORY-P function than I would about
firming up the rules on canonicalization of truenames. For example,
might not someone want a LINK-P function, a DEVICE-P function, a
RAW-DEVICE-P function, etc. Where does it stop. Do we really know
enough about all the possible file system architectures to have a
FILE-TYPE function that returns some type key?
(Perhaps unlike Unix stat(), FILE-TYPE might return an
implementation-specific object instance, with multiple-inheritance to
support a number of standard-defined base classes. But then, wouldn't
it really be better to have different classes of truenames that did this
so that the truename objects was of the right class instead of having to
use a separate predicate (other than class-of) in order to get a dummy
type object? In other words, it's an open ended design issue that is
not yet ripe for standardization. My feeling is that fine tuning the
definition of truename canonicalization, by contrast, is not so bad.)
I will be traveling and unable to defend myself for a week, so have
fun....
Here is a probably portable PATHNAME-DIRECTORY-P function definition.
Tested with CMUCL,CLISP,ACL:
(defun PATHNAME-DIRECTORY-P (pathname)
(zerop (length (file-namestring pathname))))
The (zerop ..) stuff is necessary, because some impl's return "", others
return NIL for empty file-names.
Bernhard
--
--------------------------------------------------------------------------
Bernhard Pfahringer
Austrian Research Institute for http://www.ai.univie.ac.at/~bernhard/
Artificial Intelligence ········@ai.univie.ac.at
········@hummel.ai.univie.ac.at (Bernhard Pfahringer) writes:
> Here is a probably portable PATHNAME-DIRECTORY-P function definition.
> Tested with CMUCL,CLISP,ACL:
>
> (defun PATHNAME-DIRECTORY-P (pathname)
> (zerop (length (file-namestring pathname))))
>
> The (zerop ..) stuff is necessary, because some impl's return "", others
> return NIL for empty file-names.
(pathname-directory-p "/home/cbarry")
=> NIL
This function is just as intelligent as your typical implementation of
the DIRECTORY function. A function similar to this was posted a good
while ago.
Christopher
"Howard R. Stearns" <······@elwood.com> writes:
> You should be able
> to use [DIRECTORY] to devise a portable, if not very efficient, test.
Remember that thread we had about DIRECTORY and pathname matching? I
think it's impossible to do portably, because pathname matching is
underspecified in the standard and implementations diverge even from
that spec.
> My personal view is that whether or not it was intended to, the spec
> does spell some things out that, to me, require the truenames of
> directories to appear in some cannonicalized form such as having the
> name, type and version be :unspecified.
I agree, and LispWorks now does this as well. You then need a
function that returns a copy of the pathname with the name, type and
version fields set to NIL; this is useful for many other purposes as
well and avoids unreliable hackery on namestrings. In LW, it's called
PATHNAME-LOCATION.
--
Pekka P. Pirinen
Adaptive Memory Management Group, Harlequin Limited
(format t ··@?" "(format t ····@?\" ~:*~S)")
I actually have a few questions on pathname matching, is it possible
to get to that thread you're mentioning. If not:
> (setf (logical-pathname-translations "home")
'(("*.*.*" "/home/simsek/*.*.*")
("**/*.*.*" "/home/simsek/**/*.*.*")
("dev/*.*.*" "/home/simsek/dev/*.*.*")
("dev/**/*.*.*" "/home/simsek/dev/**/*.*.*")))
I have a file called home.lisp under /home/simsek/dev but:
> (probe-file "home:dev;home.lisp")
nil
If, instead, I write:
> (setf (logical-pathname-translations "home")
'(("**/*.*.*" "/home/simsek/**/*.*.*")
("dev/**/*.*.*" "/home/simsek/dev/**/*.*.*")))
> (probe-file "home:dev;home.lisp")
#p"/home/simsek/dev/home.lisp"
Is there something obvious that I'm missing?
Thanks,
Tunc
"Pekka P. Pirinen" wrote:
>
> "Howard R. Stearns" <······@elwood.com> writes:
> > You should be able
> > to use [DIRECTORY] to devise a portable, if not very efficient, test.
>
> Remember that thread we had about DIRECTORY and pathname matching? I
> think it's impossible to do portably, because pathname matching is
> underspecified in the standard and implementations diverge even from
> that spec.
>
> > My personal view is that whether or not it was intended to, the spec
> > does spell some things out that, to me, require the truenames of
> > directories to appear in some cannonicalized form such as having the
> > name, type and version be :unspecified.
>
> I agree, and LispWorks now does this as well. You then need a
> function that returns a copy of the pathname with the name, type and
> version fields set to NIL; this is useful for many other purposes as
> well and avoids unreliable hackery on namestrings. In LW, it's called
> PATHNAME-LOCATION.
> --
> Pekka P. Pirinen
> Adaptive Memory Management Group, Harlequin Limited
> (format t ··@?" "(format t ····@?\" ~:*~S)")
"H. Tunc Simsek" <······@EECS.Berkeley.Edu> writes:
> I actually have a few questions on pathname matching, is it possible
> to get to that thread you're mentioning.
That was mostly about DIRECTORY and subdirectories, so it just covered
a part of the matching issues. You can find it in Deja, but it won't
answer your question.
> If not:
>
> > (setf (logical-pathname-translations "home")
> '(("*.*.*" "/home/simsek/*.*.*")
> ("**/*.*.*" "/home/simsek/**/*.*.*")
> ("dev/*.*.*" "/home/simsek/dev/*.*.*")
> ("dev/**/*.*.*" "/home/simsek/dev/**/*.*.*")))
>[...]
> Is there something obvious that I'm missing?
Yes, a slash is not legal logical pathname syntax, you probably meant
("**;*.*.*" "/home/simsek/**/*.*.*")
etc. IWBNI your Lisp implementation gave you an error msg, instead of
producing bogus translations. Also, only the second translation is
needed, as the others are included in it.
Other than that, you need to tell us which Lisp and which platform
you're using, so we can tell if the syntax is otherwise OK. Does it
really support a syntax for versions in physical pathnames?
Finally, when you have such problems, you can try to figure out what's
going on by using TRANSLATE-LOGICAL-PATHNAME and PATHNAME-MATCH-P --
assuming of course that the implementation follows the spec. Don't
forget PROBE-FILE will merge with *DEFAULT-PATHNAME-DEFAULTS*!
--
Pekka P. Pirinen, Adaptive Memory Management Group, Harlequin Limited
"A computer lets you make more mistakes faster than any
invention in human history with the possible exceptions of handguns
and tequila." Mitch Ratliffe, _Technology Review_ April, 1992
[I'm going to raise a question and answer it, just so that DejaNews has
a record if I ever go back to it...]
Q: Why not have the cannonicalized form of directory use NIL for name,
type and version instead of :UNSPECIFIC? Then there would not need to be
a separate PATHNAME-LOCATION function.
A: Because one wants a cannonicalized form to stay canonicalized.
Explicit or implicit use of MERGE-PATHNAMES will replace NIL components
with values from the default, but won't replace :unspecific.
Pekka P. Pirinen wrote:
>
> "Howard R. Stearns" <······@elwood.com> writes:
> > You should be able
> > to use [DIRECTORY] to devise a portable, if not very efficient, test.
>
> Remember that thread we had about DIRECTORY and pathname matching? I
> think it's impossible to do portably, because pathname matching is
> underspecified in the standard and implementations diverge even from
> that spec.
>
> > My personal view is that whether or not it was intended to, the spec
> > does spell some things out that, to me, require the truenames of
> > directories to appear in some cannonicalized form such as having the
> > name, type and version be :unspecified.
>
> I agree, and LispWorks now does this as well. You then need a
> function that returns a copy of the pathname with the name, type and
> version fields set to NIL; this is useful for many other purposes as
> well and avoids unreliable hackery on namestrings. In LW, it's called
> PATHNAME-LOCATION.
> --
> Pekka P. Pirinen
> Adaptive Memory Management Group, Harlequin Limited
> (format t ··@?" "(format t ····@?\" ~:*~S)")
"Howard R. Stearns" <······@elwood.com> writes:
> Q: Why not have the canonicalized form of directory use NIL for name,
> type and version instead of :UNSPECIFIC? Then there would not need to be
> a separate PATHNAME-LOCATION function.
>
> A: Because one wants a canonicalized form to stay canonicalized.
Also, because it seems natural that a truename matches only itself,
when compared with PATHNAME-MATCH-P. As a bonus, you get a way of
saying "list all the subdirectories of this directory":
(DIRECTORY (MERGE-PATHNAMES #P"*/" (TRUENAME dir)))
--
Pekka P. Pirinen Adaptive Memory Management Group, Harlequin Limited
Don't pay for junk email. It's your private mailbox, and they're abusing
it. If you don't complain, they'll do it again. Don't hit delete, get
*them* deleted. See <URL:http://www.uk.spam.abuse.net/spam/> for info.