Jack wrote:
> I don't understand how Common Lisp finds a file when you call the
> 'load' function. Could somebody kindly explain how this works? Thanks.
It varies. On Linux (load "cells.lisp") looks in my current working
directory, in ACL on NT it looks in the directory where the ACL Lisp
image sits. You can get specific and use longer names
"teamkenny/cells/cells.lisp" (I forget which way the slashes go). or if
I was in that directory when I started: "./cells/cells.lisp".
God help you if someone tries to explain Lisp pathnames. Run screaming
if they do. :)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<················@nyc.rr.com>...
> Jack wrote:
> > I don't understand how Common Lisp finds a file when you call the
> > 'load' function. Could somebody kindly explain how this works? Thanks.
>
> It varies. On Linux (load "cells.lisp") looks in my current working
> directory, in ACL on NT it looks in the directory where the ACL Lisp
> image sits. You can get specific and use longer names
> "teamkenny/cells/cells.lisp" (I forget which way the slashes go). or if
> I was in that directory when I started: "./cells/cells.lisp".
>
> God help you if someone tries to explain Lisp pathnames. Run screaming
> if they do. :)
>
>
> Thanks Kenny. I am using ACL on NT. If the file I want to load is in a directory other than where the Lisp image sits, what does Lisp do then? I understand there are variables that are relevant here (*default-pathname-defaults* for example) but I don't have a crystal clear idea of what Lisp does.
I realize this is an elementary question and I do appreciate your responses. Thanks.
> --
>
> kenny tilton
> clinisys, inc
> http://www.tilton-technology.com/
> ---------------------------------------------------------------
> "Career highlights? I had two. I got an intentional walk from
> Sandy Koufax and I got out of a rundown against the Mets."
> -- Bob Uecker
Jack wrote:
> Kenny Tilton <·······@nyc.rr.com> wrote in message news:<················@nyc.rr.com>...
>
>>Jack wrote:
>>
>>>I don't understand how Common Lisp finds a file when you call the
>>>'load' function. Could somebody kindly explain how this works? Thanks.
>>
>>It varies. On Linux (load "cells.lisp") looks in my current working
>>directory, in ACL on NT it looks in the directory where the ACL Lisp
>>image sits. You can get specific and use longer names
>>"teamkenny/cells/cells.lisp" (I forget which way the slashes go). or if
>>I was in that directory when I started: "./cells/cells.lisp".
>>
>>God help you if someone tries to explain Lisp pathnames. Run screaming
>>if they do. :)
>>
>>
>>Thanks Kenny. I am using ACL on NT. If the file I want to load is in a directory other than where the Lisp image sits, what does Lisp do then? I understand there are variables that are relevant here (*default-pathname-defaults* for example) but I don't have a crystal clear idea of what Lisp does.
This just worked for me (on ACL/NT):
(load "d:/__teamkenny/cells/cells.lisp")
btw, yes, I actually started the folder name with two underscores. :)
Notice that the slashes go the other way than shown in, say, Win
Explorer. To use backslashes, this just worked for me:
(load "d:\\__teamkenny\\cells\\cells.lisp")
Backslash is the escape character, so you need two to get one.
>
> I realize this is an elementary question and I do appreciate your responses. Thanks.
No problemo.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
··········@circusry.com (Jack) writes:
> Thanks Kenny. I am using ACL on NT. If the file I want to load is in
> a directory other than where the Lisp image sits, what does Lisp do
> then? I understand there are variables that are relevant here
> (*default-pathname-defaults* for example) but I don't have a crystal
> clear idea of what Lisp does.
Lisp itself will probably fail to find the file if all you give is the
filename. It will then throw an error.
The simplest solution is that you give a full pathname. At least that
way, you're sure that both you and lisp agree on which file is being
loaded.
There are other shortcuts that involve defaulting the pathname in
various ways, but that gets a bit more complicated. And to use them,
you would still have to specify the pathname at least once.
--
Thomas A. Russ, USC/Information Sciences Institute
Kenny Tilton <·······@nyc.rr.com> writes:
> Jack wrote:
> > I don't understand how Common Lisp finds a file when you call the
> > 'load' function. Could somebody kindly explain how this works? Thanks.
>
> It varies. On Linux (load "cells.lisp") looks in my current working
> directory, in ACL on NT it looks in the directory where the ACL Lisp
> image sits. You can get specific and use longer names
> "teamkenny/cells/cells.lisp" (I forget which way the slashes go). or
> if I was in that directory when I started: "./cells/cells.lisp".
Yes, the point against which pathnames are merged is necessarily
implementation-defined.
> God help you if someone tries to explain Lisp pathnames. Run screaming
> if they do. :)
Hey, don't make fun! Pathnames have some details to learn, and are
messily specified in a few ways, but are as conceptually simple as can
be. Why do you think otherwise?
Kent M Pitman wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Jack wrote:
>>
>>>I don't understand how Common Lisp finds a file when you call the
>>>'load' function. Could somebody kindly explain how this works? Thanks.
>>
>>It varies. On Linux (load "cells.lisp") looks in my current working
>>directory, in ACL on NT it looks in the directory where the ACL Lisp
>>image sits. You can get specific and use longer names
>>"teamkenny/cells/cells.lisp" (I forget which way the slashes go). or
>>if I was in that directory when I started: "./cells/cells.lisp".
>
>
> Yes, the point against which pathnames are merged is necessarily
> implementation-defined.
>
>
>>God help you if someone tries to explain Lisp pathnames. Run screaming
>>if they do. :)
>
>
> Hey, don't make fun! Pathnames have some details to learn, and are
> messily specified in a few ways, but are as conceptually simple as can
> be. Why do you think otherwise?
AAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHAAAAAAAAAAAAAAAAAAAEIIIIIIIIIIIIIIIIIII!
<slam>
A good logical pathname looks like Perl. And the damn mechanism has a
keyword called :wild-inferiors. 'Nuff said?
:)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
From: Joe Marshall
Subject: Re: newbie question about loading files
Date:
Message-ID: <3cftisbp.fsf@ccs.neu.edu>
Kent M Pitman <······@world.std.com> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>> Jack wrote:
>> > I don't understand how Common Lisp finds a file when you call the
>> > 'load' function. Could somebody kindly explain how this works? Thanks.
>>
>> It varies. On Linux (load "cells.lisp") looks in my current working
>> directory, in ACL on NT it looks in the directory where the ACL Lisp
>> image sits. You can get specific and use longer names
>> "teamkenny/cells/cells.lisp" (I forget which way the slashes go). or
>> if I was in that directory when I started: "./cells/cells.lisp".
>
> Yes, the point against which pathnames are merged is necessarily
> implementation-defined.
*default-pathname-defaults* anyone?
You shouldn't hand relative pathnames to the underlying
implementation substrate. All sorts of unexpected things can occurs.
From: Christopher C. Stacy
Subject: Re: newbie question about loading files
Date:
Message-ID: <u3cfu4gpi.fsf@dtpq.com>
>>>>> On 21 Aug 2003 14:18:37 -0700, Jack ("Jack") writes:
Jack> I don't understand how Common Lisp finds a file when you call the
Jack> 'load' function. Could somebody kindly explain how this works? Thanks.
There is generally some implementation-specific (operating system + Lisp
system) notion of a "current directory" or "working directory" which is
used, unless you specified the directory in the pathname you asked to LOAD.
The system could be designed to do anything, such as: look in
"My Documents and Folders", or the directory the Lisp executable was
started from (or the "Start In" property of a shortcut), or it could
look at a HOME environment variable or something, On Unix, I assume
most implementations look in the your current working directory (your
login home directory, or where you last did `cd`). So, you need to
check the documentation of whatever Common Lisp system you're using.
In any event, the default is based on the pathname stored in the
variable *DEFAULT-PATHNAME-DEFAULTS*.
Sometimes, a file might contain a recursive call to LOAD.
A common idiom in that case is for that inner call to LOAD
to default to the directory of the outer file that is being
loaded, as in the following:
(load (make-pathname :name "vwspguy" :defaults *load-truename*))
There is also the issue of whether LOAD, if you don't specify the
file type, will decide to load the source file or the compiled file.
For example, It might prefer to always load the compiled file
if there is one; or it might prefer the most recently written file.
That is also implementation dependant.
······@dtpq.com (Christopher C. Stacy) writes:
> A common idiom in that case is for that inner call to LOAD
> to default to the directory of the outer file that is being
> loaded, as in the following:
>
> (load (make-pathname :name "vwspguy" :defaults *load-truename*))
Although this is not nearly as portable as:
(load (make-pathname :name "VWSPGUY" :type nil :version nil
:case :common :defaults *load-truename*))
> There is also the issue of whether LOAD, if you don't specify the
> file type, will decide to load the source file or the compiled file.
> For example, It might prefer to always load the compiled file
> if there is one; or it might prefer the most recently written file.
> That is also implementation dependant.
Yes, that's why I specify type NIL, so that if *load-truename* is a
.bin or .lisp, you don't limit yourself to loading companion files
only of the same type.
You really also want that :version nil since on a file system with
versions, if you're loading foo.lisp.17 you don't end up trying to
load version 17 of the other...
And the :case thing is important so that on systems that are
case-sensitive, you get the preferred case (which is what uppercase
denotes in "common case"). For Unix, you'll get lowercase files if you
use uppercase :common. Keep in mind that although on Unix it feels like
:local (the default) is the opposite of :common, in the general case
it's just not.
Kent M Pitman wrote:
> ······@dtpq.com (Christopher C. Stacy) writes:
>
>>A common idiom in that case is for that inner call to LOAD
>>to default to the directory of the outer file that is being
>>loaded, as in the following:
>
> Although this is not nearly as portable as:
>
> (load (make-pathname :name "VWSPGUY" :type nil :version nil
> :case :common :defaults *load-truename*))
I wouldn't put code like the above in a system that didn't already
know something about the kinds of pathnames being passed to the
outer load. If the outer call received a logical pathname, the
merged pathname might not be the same as the translation of a merged
*load-pathname*. One typical use of logical pathnames is to permit
storage of different types of files with similar logical pathnames
in different physical directories.
In other words, CL pathnames are way too powerful and you can't
manipulate them without knowing how they are being used.
Another surprising point: Elsewhere in this thread the issue of
`current directory' is discussed. I'll point out that if a CL
pathname, after merging and translation, has a relative directory
component, the ANS assigns absolutely no semantics whatever to
what OPEN etc. do with it. The ANS documents the concept of
current directory only as the source for an initial value of
*default-pathname-defaults*. There is no concept that the
underlying OS would find a file relative to this system concept
of current directory, which might or might not have anything to
do with the current value of *d-p-d*.
I conclude that it "is an error" to pass to OPEN a pathname that
is relative after merging and translation. An implementation is
free to define the behavior, and the obvious intuitive behavior is
probably the right one, but an implementation that signalled error
in this situation would also be correct and reasonable.
"Steven M. Haflich" <·················@alum.mit.edu> writes:
> Another surprising point: Elsewhere in this thread the issue of
> `current directory' is discussed. I'll point out that if a CL
> pathname, after merging and translation, has a relative directory
> component, the ANS assigns absolutely no semantics whatever to
> what OPEN etc. do with it. The ANS documents the concept of
> current directory only as the source for an initial value of
> *default-pathname-defaults*. There is no concept that the
> underlying OS would find a file relative to this system concept
> of current directory, which might or might not have anything to
> do with the current value of *d-p-d*.
CLHS 19.2.3
Except as explicitly specified otherwise, for functions that
manipulate or inquire about files in the file system, the pathname
argument to such a function is merged with
*default-pathname-defaults* before accessing the file system (as if
by merge-pathnames).
If *default-pathname-defaults* has a relative pathname, then yes, you
lose, but if your implementation starts up with a relative
*default-pathname-defaults*, I suggest you complain to your vendor; if
you set or bind *default-pathname-defaults* to a relative pathname
around a call that touches the filesystem, then you deserve all you
get.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes <·····@cam.ac.uk> writes:
> "Steven M. Haflich" <·················@alum.mit.edu> writes:
>
> > Another surprising point: Elsewhere in this thread the issue of
> > `current directory' is discussed. I'll point out that if a CL
> > pathname, after merging and translation, has a relative directory
> > component, the ANS assigns absolutely no semantics whatever to
> > what OPEN etc. do with it. The ANS documents the concept of
> > current directory only as the source for an initial value of
> > *default-pathname-defaults*. There is no concept that the
> > underlying OS would find a file relative to this system concept
> > of current directory, which might or might not have anything to
> > do with the current value of *d-p-d*.
>
> CLHS 19.2.3
>
> Except as explicitly specified otherwise, for functions that
> manipulate or inquire about files in the file system, the pathname
> argument to such a function is merged with
> *default-pathname-defaults* before accessing the file system (as if
> by merge-pathnames).
>
> If *default-pathname-defaults* has a relative pathname, then yes, you
> lose, but if your implementation starts up with a relative
> *default-pathname-defaults*, I suggest you complain to your vendor; if
> you set or bind *default-pathname-defaults* to a relative pathname
> around a call that touches the filesystem, then you deserve all you
> get.
I mostly agree, but would say instead:
If the implementation comes up with a relative *default-pathname-defaults*
and does not treat such situations meaningfully by merging, too, against
the working dir, then you should complain.
Any time I see a relative pathname there, I assume it's because the
implementation means to allow show-through of the working dir.
I don't consider this any more dangerous than any file reference, even
an absolute one. After all, one can't access _any_ files without assuring
they are present.
Further, I think the issue about logical pathnames smh raises is strictly
true but largely irrelevant in practice, in the sense that one doesn't
design calls to load in isolation of knowing what's in the file system.
Either you design the code and then you make the file system match the
code's need (in which case it's not an issue) or else you design the file
arrangement and then you write the code to match (in which case it's also
not an issue). While it's possible to speak about pathological situations
that assume you have neither designed the code around the file system nor
vice versa, that comes under the issue of "just plain bad design strategy"
in my book and not under the "caveats of use of this particular set of
operators".