[Openmcl-devel] %directory-string-list fails on real Mac filenames

[Stonewall Ballard]

Gary,

That's clearly a better idea than what I was considering, but it 
doesn't work. It fails on a file named "11 *69.mp3", which produces:

Illegal use of wildcarded filename "/Volumes/Music/iTunes 
Music/Christine Lavin/Please Don't Make Me Too Happy/11 \\\\*69.mp3"
While executing: NATIVE-TRANSLATED-NAMESTRING

I'll take a look at this later when I have more time.

BTW, I'm making an effort here to see if I can use OpenMCL as a 
convenient scripting language. I've been using Python, but I'd rather 
write in Lisp.

Thanks.

  - Stoney

On Mar 26, 2004, at 12:54 AM, Gary Byers wrote:

> I think that the function's used to parse directory components of
> (possibly logical) namestrings as well, so it doesn't want to have
> to guess what:
>
> "/;abc;/def/;ghi;"
>
> might mean.  (As the comment indicates, an explicit host - or explicit
> lack of a host - might make this unambiguous.)
>
> If we're going to be picky about insisting that semicolons be quoted,
> we should ensure that "native" namestrings returned by file-system
> functions get any semicolons they might contain escaped.  The function
> CCL::NATIVE-TO-PATHNAME will current quote asterisks (not a bad idea 
> ...);
> It seems to me that it should quote semicolons (and possibly colons) as
> well (and likewise for CCL::NATIVE-TO-DIRECTORY-PATHNAME):
>
>
> (defun native-to-pathname (name)
>   (pathname (%path-std-quotes name nil "*;:")))
>
> (defun native-to-directory-pathname (name)
>   (make-directory-pathname  :device nil :directory (%path-std-quotes 
> name nil "*;:")))
>
> With those changes in effect, I did:
>
> [~] gb at zatoichi> mkdir dir
> [~] gb at zatoichi> mkdir dir/semi\;path/
> [~] gb at zatoichi> touch dir/semi\;path/file
>
> in a shell and did:
>
> ? (directory "home:dir;**;*.*")
>
> which returned
>
> (#P"/Users/gb/dir/semi\\;path/file")
>
> Is that similar to what you were trying to do, and does it fix the 
> problem ?