uiop parse-native-namestring portability?
Hi, Should I be able to expect the following to behave consistently across Lisps? (file-namestring (uiop:parse-native-namestring ".")) I find that: - CCL and SBCL produce "." - Allegro produces NIL - CMUCL signals an error in LISP::UNPARSE-UNIX-FILE If I just look at: (uiop:parse-native-namestring ".") I get: Allegro: #P"./" CCL: #P"." SBCL: #P"." CMUCL: #P(:NAME "." :TYPE :UNSPECIFIC) Cheers, Jared -- Jared C. Davis <jared@cs.utexas.edu> 11410 Windermere Meadows Austin, TX 78759 http://www.cs.utexas.edu/users/jared/
Good luck convincing 7 active implementations to agree on how to parse that. If you know the path is relative and you want portability, try uiop:parse-unix-namestring. But even then, things get ugly when you reach wildcard characters. CL pathname parsing is a huge mess. If you want to fix it, I suggest: 1- defining exactly what you think the correct behavior should be, and implement it in iolib 2- send patches to SBCL, CCL, CLISP, ABCL, CMUCL, ECL, and/or MKCL so they can agree. 3- once the patches are in more than two free software implementations, file bugs against Allegro, LispWorks 4- forget about SCL, GCL, MCL, Corman, Genera, XCL. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The mice which helplessly find themselves between the cats teeth acquire no merit from their enforced sacrifice. — Mahatma Gandhi 4- —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org On Thu, Jan 7, 2016 at 11:22 AM, Jared C. Davis <jared.c.davis@gmail.com> wrote:
Hi,
Should I be able to expect the following to behave consistently across Lisps?
(file-namestring (uiop:parse-native-namestring "."))
I find that:
- CCL and SBCL produce "." - Allegro produces NIL - CMUCL signals an error in LISP::UNPARSE-UNIX-FILE
If I just look at:
(uiop:parse-native-namestring ".")
I get:
Allegro: #P"./" CCL: #P"." SBCL: #P"." CMUCL: #P(:NAME "." :TYPE :UNSPECIFIC)
Cheers, Jared
-- Jared C. Davis <jared@cs.utexas.edu> 11410 Windermere Meadows Austin, TX 78759 http://www.cs.utexas.edu/users/jared/
On 1/7/16 Jan 7 -10:34 AM, Faré wrote:
Good luck convincing 7 active implementations to agree on how to parse that. If you know the path is relative and you want portability, try uiop:parse-unix-namestring. But even then, things get ugly when you reach wildcard characters.
I guess I'm not sure I understand. Why is it necessary to get the active implementations to agree on how to parse this? Isn't it an alternative to interpret the substring "." using *default-pathname-defaults* and ".." using *default-pathname-defaults* and :relative :back? I'm sure you understand this far better than I do, so perhaps there's something that makes this a non-starter.... Best, r
On Thu, Jan 7, 2016 at 4:17 PM, Robert Goldman <rpgoldman@sift.net> wrote:
On 1/7/16 Jan 7 -10:34 AM, Faré wrote:
Good luck convincing 7 active implementations to agree on how to parse that. If you know the path is relative and you want portability, try uiop:parse-unix-namestring. But even then, things get ugly when you reach wildcard characters.
I guess I'm not sure I understand. Why is it necessary to get the active implementations to agree on how to parse this? Isn't it an alternative to interpret the substring "." using *default-pathname-defaults* and ".." using *default-pathname-defaults* and :relative :back?
I'm sure you understand this far better than I do, so perhaps there's something that makes this a non-starter....
The CLHS leaves pathname parsing totally non-portable. *Some* implementations also have some primitive to parse native namestrings, and UIOP exposes that in a semi-portable way to users. I see that ADSF 3.1.6.8 only had recipes for SBCL and CCL — I just added some recipes for parse-native-namestring for CMUCL and SCL, that mirror the already present recipes for native-namestring. I welcome patches to better support other implementations. Please try 3.1.6.9 which also fixes lp#1531887. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Justice is not concerned with the results of the various transactions but only with whether the transactions themselves are fair. — F.A. Hayek, "Law, Legislation and Liberty", I.6.j
"Jared" == Jared C Davis <jared.c.davis@gmail.com> writes:
Jared> Hi, Jared> Should I be able to expect the following to behave consistently across Lisps? Jared> (file-namestring (uiop:parse-native-namestring ".")) Jared> I find that: Jared> - CCL and SBCL produce "." Jared> - Allegro produces NIL Jared> - CMUCL signals an error in LISP::UNPARSE-UNIX-FILE Jared> If I just look at: Jared> (uiop:parse-native-namestring ".") Jared> I get: Jared> Allegro: #P"./" Jared> CCL: #P"." Jared> SBCL: #P"." Jared> CMUCL: #P(:NAME "." :TYPE :UNSPECIFIC) I wonder why uiop:parse-native-namestring does that on cmucl. (cl:parse-namestring ".") returns #p"./", which, I think, makes sense. Without examining the actual slots, it's hard to tell what #p"." really is. -- Ray
Hi, Ah, I should have though to include the components instead of the #P format. Here's what I get on the various Lisps for: (defun show (x) (list :host (pathname-host x) :device (pathname-device x) :directory (pathname-directory x) :name (pathname-name x) :type (pathname-type x) :version (pathname-version x))) (show (uiop:parse-native-namestring ".")) Cheers, Jared CCL: (:HOST :UNSPECIFIC :DEVICE NIL :DIRECTORY NIL :NAME NIL :TYPE "" :VERSION NIL) SBCL: (:HOST #<SB-IMPL::UNIX-HOST {1000F38E53}> :DEVICE NIL :DIRECTORY (:RELATIVE) :NAME "." :TYPE NIL :VERSION NIL) Allegro: (:HOST NIL :DEVICE :UNSPECIFIC :DIRECTORY (:RELATIVE) :NAME NIL :TYPE NIL :VERSION :UNSPECIFIC) CMUCL: (:HOST "" :DEVICE NIL :DIRECTORY NIL :NAME "." :TYPE :UNSPECIFIC :VERSION NIL) On Thu, Jan 7, 2016 at 10:43 AM, Raymond Toy <toy.raymond@gmail.com> wrote:
"Jared" == Jared C Davis <jared.c.davis@gmail.com> writes:
Jared> Hi, Jared> Should I be able to expect the following to behave consistently across Lisps?
Jared> (file-namestring (uiop:parse-native-namestring "."))
Jared> I find that:
Jared> - CCL and SBCL produce "." Jared> - Allegro produces NIL Jared> - CMUCL signals an error in LISP::UNPARSE-UNIX-FILE
Jared> If I just look at:
Jared> (uiop:parse-native-namestring ".")
Jared> I get:
Jared> Allegro: #P"./" Jared> CCL: #P"." Jared> SBCL: #P"." Jared> CMUCL: #P(:NAME "." :TYPE :UNSPECIFIC)
I wonder why uiop:parse-native-namestring does that on cmucl. (cl:parse-namestring ".") returns #p"./", which, I think, makes sense.
Without examining the actual slots, it's hard to tell what #p"." really is.
-- Ray
-- Jared C. Davis <jared@cs.utexas.edu> 11410 Windermere Meadows Austin, TX 78759 http://www.cs.utexas.edu/users/jared/
Hi, Hrmn, this also seems to provoke an error in CMUCL: * (uiop:ensure-directory-pathname (uiop:parse-native-namestring ".")) Error in function LISP::UNPARSE-UNIX-FILE: Invalid value for a pathname name: "." [Condition of type SIMPLE-ERROR] Maybe that's a clearer bug since it only involves UIOP functions and not any plain Common Lisp stuff? Cheers, Jared On Thu, Jan 7, 2016 at 10:58 AM, Jared C. Davis <jared.c.davis@gmail.com> wrote:
Hi,
Ah, I should have though to include the components instead of the #P format. Here's what I get on the various Lisps for:
(defun show (x) (list :host (pathname-host x) :device (pathname-device x) :directory (pathname-directory x) :name (pathname-name x) :type (pathname-type x) :version (pathname-version x)))
(show (uiop:parse-native-namestring "."))
Cheers, Jared
CCL: (:HOST :UNSPECIFIC :DEVICE NIL :DIRECTORY NIL :NAME NIL :TYPE "" :VERSION NIL)
SBCL: (:HOST #<SB-IMPL::UNIX-HOST {1000F38E53}> :DEVICE NIL :DIRECTORY (:RELATIVE) :NAME "." :TYPE NIL :VERSION NIL)
Allegro: (:HOST NIL :DEVICE :UNSPECIFIC :DIRECTORY (:RELATIVE) :NAME NIL :TYPE NIL :VERSION :UNSPECIFIC)
CMUCL: (:HOST "" :DEVICE NIL :DIRECTORY NIL :NAME "." :TYPE :UNSPECIFIC :VERSION NIL)
On Thu, Jan 7, 2016 at 10:43 AM, Raymond Toy <toy.raymond@gmail.com> wrote:
> "Jared" == Jared C Davis <jared.c.davis@gmail.com> writes:
Jared> Hi, Jared> Should I be able to expect the following to behave consistently across Lisps?
Jared> (file-namestring (uiop:parse-native-namestring "."))
Jared> I find that:
Jared> - CCL and SBCL produce "." Jared> - Allegro produces NIL Jared> - CMUCL signals an error in LISP::UNPARSE-UNIX-FILE
Jared> If I just look at:
Jared> (uiop:parse-native-namestring ".")
Jared> I get:
Jared> Allegro: #P"./" Jared> CCL: #P"." Jared> SBCL: #P"." Jared> CMUCL: #P(:NAME "." :TYPE :UNSPECIFIC)
I wonder why uiop:parse-native-namestring does that on cmucl. (cl:parse-namestring ".") returns #p"./", which, I think, makes sense.
Without examining the actual slots, it's hard to tell what #p"." really is.
-- Ray
-- Jared C. Davis <jared@cs.utexas.edu> 11410 Windermere Meadows Austin, TX 78759 http://www.cs.utexas.edu/users/jared/
-- Jared C. Davis <jared@cs.utexas.edu> 11410 Windermere Meadows Austin, TX 78759 http://www.cs.utexas.edu/users/jared/
"Jared" == Jared C Davis <jared.c.davis@gmail.com> writes:
Jared> Hi, Jared> Hrmn, this also seems to provoke an error in CMUCL: Jared> * (uiop:ensure-directory-pathname (uiop:parse-native-namestring ".")) Jared> Error in function LISP::UNPARSE-UNIX-FILE: Jared> Invalid value for a pathname name: "." Jared> [Condition of type SIMPLE-ERROR] Presumably this happens because on unix, there is no file with name "."; it's a directory. I think this still points to some issue in uiop:parse-native-namestring for cmucl. Your example shows that Allegro parses it the same way (cl:parse-namestring ".") does on cmucl. -- Ray
"Jared" == Jared C Davis <jared.c.davis@gmail.com> writes:
Jared> Hi, Jared> Hrmn, this also seems to provoke an error in CMUCL: Jared> * (uiop:ensure-directory-pathname (uiop:parse-native-namestring ".")) Jared> Error in function LISP::UNPARSE-UNIX-FILE: Jared> Invalid value for a pathname name: "." Jared> [Condition of type SIMPLE-ERROR] FWIW, I looked a little deeper and I see that (uiop/pathname:split-unix-namestring-directory-components "." :ensure-directory nil :dot-dot nil) returns :relative NIL "." T That means the path (directory?) is nil (and :relative), the name is "." and file-only is T. But "." is always a directory on unix, so split-unix-namestring-directory-components isn't returning what I would expect. I would expect :relative, NIL, NIL, T. (Or maybe file-only = NIL?) -- Ray
participants (4)
-
Faré -
Jared C. Davis -
Raymond Toy -
Robert Goldman