Re: DIRECTORY bugfix

Madhu wrote:
> * Paul Foley <m2wskpr44q.fsf <at> mycroft.actrix.gen.nz> :
> Wrote on Mon, 16 Jun 2008 23:49:41 +1200:
> 
> | On Mon, 16 Jun 2008 13:52:16 +0530, Madhu  wrote:
> |> I had always thought this was a feature: specifying truenamep would
> |> match behaviour of CL:TRUENAME, which would signal an error if the
> |> target was non-existant.
> |
> | I don't think DIRECTORY should error here.  I'm not sure what the
> | right thing is, though (maybe it should just ignore broken links
> | altogether?  They're not really existing files, after all...)
> 
> IME all interesting uses of CMUCL's DIRECTORY needed to use :TRUENAMEP
> NIL, i.e. invoke non ANSI behaviour [but see below for a pathological
> exception]
> 
> |> [This is not an objection to the patch, but I _was_ using this in
> |> some handlers to do the equivalent of
> |> 	 `find -type l ! -xtype f ! -xtype d'  (find dangling symlinks)
> |
> | How does it do that?  It just signals an error and doesn't return
> | anything.  ISTM you need to do (directory ... :truenamep nil) and try
> | calling truename on the results, or something...
> 
> You're right of course, and I do need to use a wrapper that does exactly
> that.  But in this one use case I wanted to note, I used vanilla
> DIRECTORY with TRUENAMEP T.  The function FIX-DANGLING-SYMLINKS caught
> the file error and offered some restarts to remove the file and fix it
> (including by hand), and then restarted the call to DIRECTORY --- the
> idea was just to correct all dangling symlinks, so the call to directory
> succeeded.

Given the previous discussions, I'm inclined NOT to change DIRECTORY.

And given Madhu's use of directory, perhaps there should be some kind of 
directory mapping function that calls a user supplied function on each 
file as the file is processed so you don't have to restart the call to 
directory from the beginning on each error.

Ray