Subject: [clisp-list] directory, symlinks.

From: "Johannes Grødem" <[email-masked]>
Date: Tue Oct 15 01:41:04 2002

* Sam Steingold

> I added :if-does-not-exists to directory in the CVS
> please try it and comment in <clisp-list>
> thanks.

Yes, this works, but I think that when you list a directory, you
should get the name of the symbolic link, not the file it points to.

Ex:

[1]> (directory #p"/tmp/test/*")
(#P"/tmp/test/arf" #P"/tmp/test/baz" #P"/tmp/test/baz" #P"/tmp/test/foo")

I get two baz here, but one of them is really a sym-link pointing to
baz.  I think it should at least be selectable whether you get the
link-name or the truename.  (As with :truenamep in CMUCL.)

(Yes, I see I can use :full to do this, but I still think it would be
more natural if it returned the name of the symbolic link.)

-- 
Johannes Grødem <OpenPGP: 5055654C>

---

From: Sam Steingold <[email-masked]>
Date: Tue Oct 15 08:37:05 2002

> * In message <[email-masked]>
> * On the subject of "[clisp-list] directory, symlinks."
> * Sent on Tue, 15 Oct 2002 10:33:05 +0200
> * Honorable "Johannes Grødem" <[email-masked]> writes:
>
> * Sam Steingold
> 

I agree.
Unfortunately for both of us, the x3j13 (the ANSI CL committee) thought
differently and required that DIRECTORY return truenames.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Small languages require big programs, large languages enable small programs.

---

From: "Johannes Grødem" <[email-masked]>
Date: Tue Oct 15 08:51:03 2002

> differently and required that DIRECTORY return truenames.

Ah, you're right.  Too bad.

By the way, doesn't it also say that directory should signal a 
file-error if it cannot get the truename of a file?  Maybe :error
should be the default parameter for if-does-not-exist?

(Oh, and you don't need to CC me.  I'm not subscribed to the list, but
I'm reading it with GMane.)

---

From: Sam Steingold <[email-masked]>
Date: Tue Oct 15 11:28:01 2002

> * In message <[email-masked]>
> * On the subject of "[clisp-list] Re: directory, symlinks."
> * Sent on Tue, 15 Oct 2002 17:50:11 +0200

backwards compatibility rules.

I can make the default depend on COSTOM:*ANSI*, but that would just add
complexity where it is not really necessary.

What do others think?

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
God had a deadline, so He wrote it all in Lisp.

---

From: Adam Warner <[email-masked]>
Date: Tue Oct 15 16:55:02 2002

> complexity where it is not really necessary.

Sam, I would like to see CLISP switch to *ansi* being t by default.

At first I would deprecate the nil setting for a couple of releases,
giving those who need backwards compatibility time to add a (setf *ansi*
nil) to their files, startup scripts or CLISP invocation. A release or
two later I would switch everything over to t.

ILISP on Debian already starts CLISP with -ansi by default.

I would like to see people new to CLISP work with conforming results.
These are the people most unlikely to know about/use the -ansi setting.
Long time users who need non-conforming functionality are the best
people to make the decision that *ansi* should be set to nil.

Regards,
Adam

---

From: Arseny Slobodjuck <[email-masked]>
Date: Tue Oct 15 17:50:02 2002

Hello Sam,

> differently and required that DIRECTORY return truenames.

And there's no way to know symbolic names of directories ?

Also, I cannot tell in windows what broken link points to - to file or directory.
I'll assume it points to file.

-- 
Best regards,
 Arseny

---

From: Arseny Slobodjuck <[email-masked]>
Date: Wed Oct 16 22:42:02 2002

Hello Sam,

Wednesday, October 16, 2002, 11:26:02 PM, you wrote:

> what for?
For those people who implement os shells on lisp.

>> Also, I cannot tell in windows what broken link points to - to file or
>> directory.  I'll assume it points to file.

> if it is broken, it does not matter where it points to - we use the
> original name.
Ah, well... Got it...

-- 
Best regards,
 Arseny