Subject: [clisp-list] fix for clisp startup problem on Win98

From: Mark Shure <[email-masked]>
Date: Wed, 16 Aug 2000 11:56:12 -0400

Thanks to advice from Don Cohen, Bruno Haible & Sam Steingold (both on and 
off the mailing list), I was able to fix my clisp startup problem on Win98 
when running the archived win32 binary.

Here is my original description of the problem (2000-08-15):
-------------------------------------------------------------------------
I just installed the clisp-2000-03-06 win32 binary on my home Win98 system. 
When I start up the program (in the c:\clisp directory) by typing 
"c:\clisp\lisp.exe -M lispinit.mem", I get the usual startup banner, a 
blank line and then the following message:

[pathname.d:6727]
*** - Win32 error 2 (ERROR_FILE_NOT_FOUND): The system cannot find the file 
specified.
1. Break [1]>

Before installing this latest version, I had been running the previous 
1999-07-22 version and was having the same problem. However, neither 
version had any problems running on my office WinNT system. Can someone 
suggest what is going on here?
-------------------------------------------------------------------------

The problem is apparently that upon startup, clisp looks for an 
initialization file called "~/.clisprc". When it can't find it, it spits 
out the ERROR_FILE_NOT_FOUND message and does not complete all of the 
program initialization. In order to avoid this error, the solution is to 
type (assuming the files are all in the "c:\clisp" directory):

c:\clisp\lisp.exe -M lispinit.mem -norc

which avoids loading the "~/.clisprc" file. You can find this option in the 
"lisp --help" message. I hadn't realized how helpful this usage message 
was! It's not clear to me why this same problem does not show up under 
WinNT, but it's hardly a surprise.

Thanks again for the help with this problem!

Regards,
Mark

============================================
Mark Shure ([email-masked])
Associate Professor
Center for High Angular Resolution Astronomy
--------------------------------------------
Georgia State University
Astronomy Offices, Suite 700
1 Park Place South SE
Atlanta GA  30303-2911
--------------------------------------------
phone:  404-651-1365
fax:    404-651-1389
============================================

---

From: Bruno Haible <[email-masked]>
Date: Wed, 16 Aug 2000 18:49:16 +0200 (CEST)

Thanks for summarizing the solution.

> It's not clear to me why this same problem does not show up under 

Windows NT defines HOMEDRIVE and HOMEPATH environment
variables. Whereas on Windows98 it's the user's responsibility to
provide a valid HOME environment variable. If HOME points to a
nonexistent directory, you will get this ERROR_FILE_NOT_FOUND.

Bruno

---

From: Sam Steingold <[email-masked]>
Date: 16 Aug 2000 15:16:25 -0400

> * In message <[email-masked]>
> * On the subject of "Re: [clisp-list] fix for clisp startup problem on Win98"
> * Sent on Wed, 16 Aug 2000 18:49:16 +0200 (CEST)
> * Honorable Bruno Haible <[email-masked]> writes:
>
yep!

> nonexistent directory, you will get this ERROR_FILE_NOT_FOUND.

WOW!  interesting.

(load "/sfg/sfg/s/dfg/sfg/sdf/g" :if-does-not-exist nil)

signals an error under CLISP but returns NIL on Allegro and CMUCL.

Shouldn't we follow suit?

ANSI says:

If the file does not exist, the specific action taken depends on
if-does-not-exist: if it is nil, load returns nil; otherwise, load
signals an error.

it appears that ANSI doesn't separate the issue of existence for files
and directories.

-- 
Sam Steingold (http://www.podval.org/~sds)
Micros**t is not the answer.  Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
Daddy, what does "format disk c: complete" mean?

---

From: Marco Antoniotti <[email-masked]>
Date: Thu, 17 Aug 2000 09:41:10 -0400

> X-Authentication-Warning: sanpietro.red-bean.com: Host centurion3.exapps.com [12.25.11.194] claimed to be xchange.com
> Cc: Mark Shure <[email-masked]>, [email-masked]
> Reply-To: [email-masked]
> Mail-Copies-To: never
> From: Sam Steingold <[email-masked]>
> User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7
> Date: 16 Aug 2000 15:16:25 -0400
> Sender: [email-masked]
> X-Mailman-Version: 1.1
> Precedence: bulk
> List-Id: CLISP user discussion <clisp-list.lists.sourceforge.net>
> X-BeenThere: [email-masked]
> Content-Type: text/plain; charset=us-ascii
> Content-Length: 1501
> 

Just to be overly nagging... :)

In LispWorks and Allegro

   (load "C:\\MyDirectory\\MyFile.FOO")

works like a charm even if C: is (obviously) not defined as a logical
pathname.  OTOH, logicla pathnames work as expected.  I.e. you do not
need to spray your code with calls to LOGICAL-PATHNAME. :)

Cheers

-- 
Marco Antoniotti =============================================================
NYU Bioinformatics Group			 tel. +1 - 212 - 998 3488
719 Broadway 12th Floor                          fax  +1 - 212 - 995 4122
New York, NY 10003, USA				 http://galt.mrl.nyu.edu/valis

---

From: Sam Steingold <[email-masked]>
Date: 17 Aug 2000 10:08:22 -0400

> * In message <[email-masked]>
> * Sent on Thu, 17 Aug 2000 09:41:10 -0400
> * Honorable Marco Antoniotti <[email-masked]> writes:
>

this behavior, while mandated by the standard, is not considered to be
reasonable by Bruno.  I agree with him that it is confusing (cf
"c:/autoexec.bat", "home:.clisprc", "ftp.gnu.org:/pub/gnu/").

I think the standard behavior can be implemented when
lisp:*pathname-ansi* is non-nil, but the standard _is_ confusing, so
this is not easy to do.

Followup-To: clisp-devel

-- 
Sam Steingold (http://www.podval.org/~sds)
Micros**t is not the answer.  Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
Programming is like sex: one mistake and you have to support it for a lifetime.

---

From: Bruno Haible <[email-masked]>
Date: Thu, 17 Aug 2000 16:12:49 +0200 (CEST)

> Shouldn't we follow suit?

Interesting, yes. Furthermore PROBE-FILE behave as you expect: no
error if the directory does not exist. It is illogical if OPEN and
LOAD behave differently.

> it appears that ANSI doesn't separate the issue of existence for files

But if the user has explictly passed :IF-DOES-NOT-EXIST NIL, he is
interested in avoiding an error in this case.

I now changed OPEN to be tolerant against non-existent directories
in the following cases:

                                :DIRECTION

:IF-DOES-NOT-EXIST   :PROBE   :INPUT   :OUTPUT   :IO
                    +--------+--------+--------+--------+
default             |   X    |        |        |        |
                    +--------+--------+--------+--------+
:ERROR              |        |        |        |        |
                    +--------+--------+--------+--------+
NIL                 |   X    |   X    |   X    |   X    |
                    +--------+--------+--------+--------+
:CREATE             |        |        |        |        |
                    +--------+--------+--------+--------+

Bruno

---

From: Marco Antoniotti <[email-masked]>
Date: Thu, 17 Aug 2000 10:45:00 -0400

> Followup-To: [email-masked]
> Cc: [email-masked]
> Reply-To: [email-masked]
> Mail-Copies-To: never
> Date: 17 Aug 2000 10:08:22 -0400
> Content-Length: 1221

Under MS systems the single letter device driver is easily special
cased for.  The second case is confusing, also because 'UNIX dot
files' do not work well with CL pathnames types (and under CMUCL more
so because of the evil SEARCH-LIST feature). The third is not a
LOGICAL-PATHNAME namestring.

If this is not enough, think of the folks at Digitool :)

> lisp:*pathname-ansi* is non-nil, but the standard _is_ confusing, so

Yes.  I agree that the standard may be confusing.  However, last time
I checked, the mandated behavior is not implemented in CLisp even when
*PATHNAME-ANSI* is non-nil.  Hence, CLisp differs from most of the
major implementations out there.  IMHO opinion, this is not anymore a
question of "ANSI compliance", but a question of "de facto standards".

Cheers