Re: ext:unix-namestring issue

Hi,

> However, in all of your examples, it seems that unix-namestring
> returns the input. If that's what you want, why not just call
> identity instead of calling unix-namestring? Or do something like
> (or (unix-namestring path) path)?
>
> I don't quite understand what you want unix-namestring to do. Do you
> have an example where you don't want the input to be returned?

(Just forwarding what Luís Oliveira attempted to send to the list):

In a nutshell, CL's namestrings have a bit of syntax that is
incompatible with the OS's pathname representation. Here's an example:

CL-USER> (namestring (make-pathname :name "*"))
"\\*"
CL-USER> (sb-ext:native-namestring (make-pathname :name "*"))
"*"


> As for the NIL result noted below, it seems that unix-namestring is
> validating that the path exists, a useful result.  But it has been a
> long time since I read those docs

I do not know what the function should do.  However, I think it is
very strange that it:

  - Returns non-NIL for some non-existent files like "hello.txt", but

  - Returns NIL for other non-existent files like "oops/hello.txt"

Cheers,
Jared

On Sat, Sep 27, 2014 at 8:56 PM, GP lisper <[email protected]> wrote:
>
> I thought I had used unix-namestring in something, but a search only
> turns up:
>>find . -type f -name "*lisp" -exec grep -H namestring "{}" \; | grep unix
> ./slime-2011-05-16/swank-cmucl.lisp:  (ext:unix-namestring (truename pathname)))
> ./slime-2011-05-16/swank-scl.lisp:  (ext:unix-namestring pathname nil))
> ./Maxima-5.14.0/configure.lisp:          #+scl (unix-namestring (ext:default-directory))
>
> as for the NIL result noted below, it seems that unix-namestring is
> validating that the path exists, a useful result.  But it has been a
> long time since I read those docs
>
>
>
>> Date: Sat, 27 Sep 2014 11:35:38 -0700
>> From: Raymond Toy <[email protected]>
>>
>> It's hard to tell exactly what unix-namestring is supposed to do since it's
>> not really well documented.
>>
>> However, in all of your examples, it seems that unix-namestring returns the
>> input. If that's what you want, why not just call identity instead of
>> calling unix-namestring? Or do something like (or (unix-namestring path)
>> path)?
>>
>> I don't quite understand what you want unix-namestring to do. Do you have
>> an example where you don't want the input to be returned?
>>
>>
>> On Fri, Sep 26, 2014 at 11:30 AM, Jared C. Davis <[email protected]>
>> wrote:
>>
>> > Hi,
>> >
>> > I am using CMUCL 20e on a Linux/x86 system.  In tracking down an issue with
>> > osilib:file-kind on CMUCL, I found the behavior of ext:unix-namestring to
>> > be
>> > somewhat surprising when parts of the input path do not exist.
>> >
>> > In particular, suppose that I have the following directory structure:
>> >
>> >     foo/            (foo is otherwise empty except for bar)
>> >      |
>> >     bar/            (bar is otherwise empty except for hello.txt)
>> >      |
>> >   hello.txt
>> >
>> > In this case, the following seem perfectly sensible and consistent:
>> >
>> >   (ext:unix-namestring "hello.txt"         nil) ; "hello.txt"
>> >   (ext:unix-namestring "foo/"              nil) ; "foo/"
>> >   (ext:unix-namestring "foo/hello.txt"     nil) ; "foo/hello.txt"
>> >   (ext:unix-namestring "foo/bar/hello.txt" nil) ; "foo/bar/hello.txt"
>> >   (ext:unix-namestring "foo/bar/bye.txt"   nil) ; "foo/bar/bye.txt"
>> >   (ext:unix-namestring "foo/bar/"          nil) ; "foo/bar/"
>> >   (ext:unix-namestring "foo/bar/baz"       nil) ; "foo/bar/baz"
>> >   (ext:unix-namestring "foo/bye.txt"       nil) ; "foo/bye.txt"
>> >   (ext:unix-namestring "bye.txt"           nil) ; "bye.txt"
>> >
>> > But it seems odd that examples such as these return NIL:
>> >
>> >   (ext:unix-namestring "oops/"                  nil) ; NIL, why not
>> > instead "oops/"?
>> >   (ext:unix-namestring "oops/hello.txt"         nil) ; NIL, why not
>> > instead "oops/hello.txt"?
>> >   (ext:unix-namestring "foo/oops/hello.txt"     nil) ; NIL, why not
>> > instead "foo/oops/hello.txt"?
>> >   (ext:unix-namestring "foo/bar/oops/hello.txt" nil) ; NIL, why not
>> > instead "foo/bar/oops/hello.txt"?
>> >   (ext:unix-namestring "foo/oops/"              nil) ; NIL, why not
>> > instead "foo/oops/"?
>> >
>> > Anyway, it seems that the NIL return is provoked any time that a missing
>> > directory is part of the path.
>> > --
>> > Jared C. Davis <[email protected]>
>
>
> --
> A bad day in () is better than a good day in {}
> _______________________________________________
> cmucl-help mailing list
> [email protected]
> http://lists.zs64.net/mailman/listinfo/cmucl-help



-- 
Jared C. Davis <[email protected]>
11410 Windermere Meadows
Austin, TX 78759
http://www.cs.utexas.edu/users/jared/
_______________________________________________
cmucl-help mailing list
[email protected]
http://lists.zs64.net/mailman/listinfo/cmucl-help