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

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" == 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