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@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
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@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@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
On Tue, Dec 31, 2013 at 1:11 AM, John Morrison jm@symbolic-simulation.com wrote:
? (merge-pathnames "foo:bar" #P"" :newest)
Error: "foo" is not a defined logical host
One could use make-pathname instead:
(make-pathname :name "foo:bar" :type nil) => #P"foo:bar"
How does this issue relate to osicat? Do you have a test case?
Cheers,
Hello Luis;
Thanks for the query, and sorry for the delay. Here is a cut-and-paste of what passes for a test-case. Basically, I have an old symbolic link hanging about, which has ":0" at the end (the X11 display number?), and which further happens to be a symbolic link to yet another old file - they are presumably created by Linux' DCOP (although I am not familiar with the details)... SBCL returns a (long) list of pathnames that includes both the symlink (with the ":0" in the pathname) and the pointed-to file.
-jm
[jm@jm7 ~]$ lx86cl64 Welcome to Clozure Common Lisp Version 1.9-r15870 (LinuxX8664)! ? (ql:quickload :osicat) To load "osicat": Load 1 ASDF system: osicat ; Loading "osicat"
(:OSICAT) ? (osicat:list-directory #P"/home/jm")
Error: ".DCOPserver_jm4_" 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 > :b (2B1F9EEA9710) : 0 (PATHNAME-HOST-SSTR ".DCOPserver_jm4_:0" 0 18 NIL) 365 (2B1F9EEA9768) : 1 (STRING-TO-PATHNAME ".DCOPserver_jm4_:0" 0 18 NIL #P"") 789 (2B1F9EEA9830) : 2 (MERGE-PATHNAMES ".DCOPserver_jm4_:0" #P"" :NEWEST) 213 (2B1F9EEA9888) : 3 (TRANSLATED-NAMESTRING ".DCOPserver_jm4_:0") 37 (2B1F9EEA98A0) : 4 (NATIVE-TRANSLATED-NAMESTRING ".DCOPserver_jm4_:0") 85 (2B1F9EEA98D8) : 5 (GET-FILE-KIND ".DCOPserver_jm4_:0" T) 45 (2B1F9EEA98F8) : 6 (FUNCALL #'#<(:INTERNAL OSICAT::ONE-ITER OSICAT::CALL-WITH-DIRECTORY-ITERATOR)>) 205 (2B1F9EEA9918) : 7 (FUNCALL #'#<(:INTERNAL OSICAT:LIST-DIRECTORY)> #<COMPILED-LEXICAL-CLOSURE (:INTERNAL OSICAT::ONE-ITER OSICAT::CALL-WITH-DIRECTORY-ITERATOR) #x302001C8A24F>) 197 (2B1F9EEA9958) : 8 (CALL-WITH-DIRECTORY-ITERATOR #P"/home/jm/" #<COMPILED-LEXICAL-CLOSURE (:INTERNAL OSICAT:LIST-DIRECTORY) #x302001C8A4FF>) 493 (2B1F9EEA99E8) : 9 (LIST-DIRECTORY #P"/home/jm" :BARE-PATHNAMES NIL) 285 (2B1F9EEA9A20) : 10 (CALL-CHECK-REGS OSICAT:LIST-DIRECTORY #P"/home/jm") 221 (2B1F9EEA9A58) : 11 (TOPLEVEL-EVAL (OSICAT:LIST-DIRECTORY #P"/home/jm") NIL) 709 (2B1F9EEA9AF8) : 12 (READ-LOOP :INPUT-STREAM #<SYNONYM-STREAM to *TERMINAL-IO* #x3020006B541D> :OUTPUT-STREAM #<SYNONYM-STREAM to *TERMINAL-IO* #x3020006B52BD> :BREAK-LEVEL 0 :PROMPT-FUNCTION #<Compiled-function (:INTERNAL CCL::READ-LOOP) (Non-Global) #x30000052D2BF>) 2309 (2B1F9EEA9D58) : 13 (RUN-READ-LOOP :BREAK-LEVEL 0) 157 (2B1F9EEA9D80) : 14 (TOPLEVEL-LOOP) 101 (2B1F9EEA9DA8) : 15 (FUNCALL #'#<(:INTERNAL (TOPLEVEL-FUNCTION (CCL::LISP-DEVELOPMENT-SYSTEM T)))>) 101 (2B1F9EEA9DC8) : 16 (FUNCALL #'#<(:INTERNAL CCL::MAKE-MCL-LISTENER-PROCESS)>) 645 (2B1F9EEA9E60) : 17 (RUN-PROCESS-INITIAL-FORM #<TTY-LISTENER listener(1) [Active] #x3020006B439D> (#<COMPILED-LEXICAL-CLOSURE # #x3020006B3ECF>)) 709 (2B1F9EEA9EF0) : 18 (FUNCALL #'#<(:INTERNAL (CCL::%PROCESS-PRESET-INTERNAL (PROCESS)))> #<TTY-LISTENER listener(1) [Active] #x3020006B439D> (#<COMPILED-LEXICAL-CLOSURE # #x3020006B3ECF>)) 573 (2B1F9EEA9F98) : 19 (FUNCALL #'#<(:INTERNAL CCL::THREAD-MAKE-STARTUP-FUNCTION)>) 277 1 > :q ? (quit) [jm@jm7 ~]$ ls -lh .*DCOPserver_jm4* -rw-r--r--. 1 jm users 50 Jan 9 2009 .DCOPserver_jm4__0 lrwxrwxrwx. 1 jm users 27 Sep 6 2008 .DCOPserver_jm4_:0 -> /home/jm/.DCOPserver_jm4__0 [jm@jm7 ~]$
On Mon, Jan 6, 2014 at 7:34 PM, Luís Oliveira loliveira@common-lisp.netwrote:
On Tue, Dec 31, 2013 at 1:11 AM, John Morrison jm@symbolic-simulation.com wrote:
? (merge-pathnames "foo:bar" #P"" :newest)
Error: "foo" is not a defined logical host
One could use make-pathname instead:
(make-pathname :name "foo:bar" :type nil) => #P"foo:bar"
How does this issue relate to osicat? Do you have a test case?
Cheers,
-- Luís Oliveira http://kerno.org/~luis/
On Wed, Jan 8, 2014 at 2:24 PM, John Morrison jm@symbolic-simulation.com wrote:
Thanks for the query, and sorry for the delay. Here is a cut-and-paste of what passes for a test-case. Basically, I have an old symbolic link hanging about, which has ":0" at the end (the X11 display number?), and which further happens to be a symbolic link to yet another old file - they are presumably created by Linux' DCOP (although I am not familiar with the details)... SBCL returns a (long) list of pathnames that includes both the symlink (with the ":0" in the pathname) and the pointed-to file.
John, do you want to have a go at fixing Osicat to use uiop:parse-native-namestring? (Please send a pull request to https://github.com/luismbo/osicat.) Adding regression tests for this bug, would nice as well.
Faré, is UIOP installable via quicklisp or is it distributed bundled with ASDF only? I'd like to use PARSE-NATIVE-NAMESTRING without depending on a specific version of ASDF.
If it isn't, I suppose we have to either (a) depend on a specific version of ASDF (how is that done?), (b) figure out a way to have UIOP as an independent library, or (c) import parse-native-namestring into Osicat.
Cheers,
On Wed, Jan 8, 2014 at 10:34 AM, Luís Oliveira loliveira@common-lisp.net wrote:
On Wed, Jan 8, 2014 at 2:24 PM, John Morrison jm@symbolic-simulation.com wrote: Faré, is UIOP installable via quicklisp or is it distributed bundled with ASDF only? I'd like to use PARSE-NATIVE-NAMESTRING without depending on a specific version of ASDF.
UIOP is in quicklisp, and can be loaded by Quicklisp's ASDF 2.26. To avoid redundant loading (and function redefinition warnings), I recommend specifying :depends-on (#-asdf3 :uiop), though :depends-on (:uiop) works, too.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A hen is just the egg's way of making another egg — Samuel Butler, 1872 People are DNA's way of making more DNA — Edward O. Wilson, 1975
On Wed, Jan 8, 2014 at 4:41 PM, Faré fahree@gmail.com wrote:
UIOP is in quicklisp, and can be loaded by Quicklisp's ASDF 2.26. To avoid redundant loading (and function redefinition warnings), I recommend specifying :depends-on (#-asdf3 :uiop), though :depends-on (:uiop) works, too.
Great! John, what say you?
-
Faré -
John Morrison -
Luís Oliveira