[cmucl-help] ext:unix-namestring issue

Raymond Toy toy.raymond at gmail.com
Sat Sep 27 18:35:38 UTC 2014


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 <jared at cs.utexas.edu>
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.  But it seems (to me) to be rather odd to
> regard
> a path such as "foo/oops/hello.txt" as any different from "foo/hello.txt",
> since neither points to a real file.
>
> I believe this affects at least the uiop and osicat libraries.
>
> For uiop, it appears that uiop:native-namestring behaves identically to the
> above examples on CMUCL.  In contrast, on each of CCL, SBCL, CLISP,
> Allegro,
> and Lispworks, uiop:native-namestring returns the strings above intead of
> NIL.
>
> For osicat, ext:unix-namestring is used in at least the implementation of
> file-kind, causing unexpected errors on certain paths.  (Details can be
> found
> within this Github issue: https://github.com/osicat/osicat/issues/2)
>
> At any rate, does this seem like a bug?  Perhaps ext:unix-namestring's
> behavior
> be updated to match these other Lisps?
>
> Thanks,
> Jared
>
> --
> Jared C. Davis <jared at cs.utexas.edu>
> 11410 Windermere Meadows
> Austin, TX 78759
> http://www.cs.utexas.edu/users/jared/
> _______________________________________________
> cmucl-help mailing list
> cmucl-help at cmucl.cons.org
> http://lists.zs64.net/mailman/listinfo/cmucl-help
>



-- 
Ray


More information about the cmucl-help mailing list