colons in pathnames - SBCL vs CCL

[Faré]

I would recommend against using "logical" pathnames in general.
They are active braindamage.
For pathnames that use : and native pathnames in general,
I recommend you use uiop:parse-native-namestring, and for portability,
uiop:parse-unix-namestring.
Use uiop:subpathname for files under trees you control.
For greater control, and dealing with files with arbitrary names under
trees you don't control, use iolib.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
You live and learn. Or you don't live long.
        — Robert Heinlein, "Time Enough For Love"


On Mon, Dec 30, 2013 at 8:11 PM, John Morrison
<jm at symbolic-simulation.com> wrote:
> Ran into CCL (but not SBCL) choking on filenames that contain colons (it
> interprets them as logical hosts, regardless of the fact they're not
> recognized ones -- and in contravention of the CLHS?).
>
> Seems like the divergence in behavior between CCL and SBCL is in
> merge-pathnames - below the level of osicat.
>
> My perhaps naive and overly simplistic expectation of behavior is that of
> SBCL (not choking, arguably closer adherence to CLHS).
>
> [jm at jm7 ~]$ lx86cl64
> Welcome to Clozure Common Lisp Version 1.9-r15870 (LinuxX8664)!
> ? (merge-pathnames "foo:bar" #P"" :newest)
>> Error: "foo" is not a defined logical host
>> While executing: CCL::PATHNAME-HOST-SSTR, in process listener(1).
>> Type :POP to abort, :R for a list of available restarts.
>> Type :? for other options.
> 1 > (apropos "host-translations")
> CCL::%LOGICAL-HOST-TRANSLATIONS%, Value: (("ccl" (#P"ccl:l1;**;*.*"
> #P"ccl:level-1;**;*.*") (#P"ccl:l1f;**;*.*" #P"ccl:l1-fasls;**;*.*")
> (#P"ccl:ccl;*.*" #P"/opt/ccl/*.*") (#P"ccl:**;*.*" #P"/opt/ccl/**/*.*"))
> ("home" (#P"home:**;*.*" #P"/home/jm/**/*.*")))
>
> Found this when rehabbing the ancient CLIM "indented-lists" tree widget,
> replacing the buggy (in CCL again) pathname hackery therein with osicat
> (which cleaned up the code).  Turns out dbus/dcop create these
> files/symlinks in one's home directory, so it's not like I went looking for
> corner cases...  If possible, I would of course prefer to be able to rely on
> osicat or the like to insulate me from system or implementation-dependent
> behavior.  Does anybody have any guidance?
>
> Thanks in advance.
>
> -jm
>