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

[Gary Byers]

On Thu, 25 Mar 2004, Stonewall Ballard wrote:

> I just discovered that in OpenMCL (at least, 0.14.1)
> %directory-string-list fails with files in my iTunes Music folder,
> apparently due to semicolons in the filenames.
>
> Try #P";/"
>
> I get Error in process listener(1): Illegal directory string ";/"
> While executing CCL::%DIRECTORY-STRING-LIST
>
> I see the comment in %directory-string-list, but this is happening
> inside a call to "directory", so I don't have an opportunity to escape
> the semicolon.

I'm not sure that it's that unreasonable to insist that a namestring
not contain multiple unquoted metacharacters.  (Even if it's
unambiguous in cases like your example, where the lack of an explicit
host: implies a physical namestring.)



>
> I need to fix this somehow. Would it hurt to remove awareness of
> semicolons from  %directory-string-list? I'm not clear on what they're
> used for.
>

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 ?

> Thanks.
>
>   - Stoney
>