Sender: tkb@BONDK
Newsgroups: comp.lang.lisp
Subject: Re: clisp installation
References: <Pine.OSF.3.95.970307185423.12568A-100000@leonis.nus.sg>
	<5fpvar$o6e$1@nz12.rz.uni-karlsruhe.de>
	<86pvx5wbji.fsf@g.pet.cam.ac.uk>
From: thomas.k.bond@cpmx.saic.com (T. Kurt Bond)
Date: 12 Mar 1997 10:14:04 -0500
Message-ID: <u3eu187nn.fsf@bondk.psds.saic.com>
Lines: 21
X-Newsreader: Gnus v5.3/Emacs 19.34
Path: cantaloupe.srv.cs.cmu.edu!nntp.club.cc.cmu.edu!goldenapple.srv.cs.cmu.edu!rochester!cornellcs!newsstand.cit.cornell.edu!portc01.blue.aol.com!newsxfer3.itd.umich.edu!howland.erols.net!news.mathworks.com!mvb.saic.com!news.saic.com!bondk.psds.saic.com!usenet
Nntp-Posting-Host: News.Saic.Com

Gareth McCaughan <gjm11@dpmms.cam.ac.uk> writes:
> Bruno Haible wrote:
> > Why does CLISP behave so strange when you type in the name of a nonexistent
> > file? It assumes that the file (without extension ".lsp") exists somewhere
> > below your $HOME directory and starts searching. In your case there is
> > apparently somewhere a symbolic link to / , and when the search examines
> > /proc on Linux, it falls into some pitfall. Sorry.
> aargh, you mean it searches the entire directory tree under your home
> directory? ouch.

Actually, if you look at the definition of *load-paths* in config.lsp before 
you compile it, you find it is
	(defparameter *load-paths* '(#"./" #"./**/" "~/**/"))
which you can change to just 
	(defparameter *load-paths* '(#"./"))
which I think restricts this searching to just the current directory.

Of course, this can cause problems with applications that assume the original 
definition of *load-paths*.
-- 
T. Kurt Bond, Thomas.K.Bond@cpmx.saic.com
