Re: ext:unix-namestring issue

For what it is worth, the return value of unix-namestring on 18a differs
from 20c but it agrees with the expected results.  A trace of the various
%enumerate-* functions that the recursion in %enumerate-directories is
behaving differently.  The implementation of %enumerate-directories changed
in version 1e8bacb7 and has not changed since.  The regression might be
there.

On Sat, Sep 27, 2014 at 11:35 AM, Raymond Toy <[email protected]> wrote:

> 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.  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 <[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
> >
>
>
>
> --
> Ray
> _______________________________________________
> cmucl-help mailing list
> [email protected]
> http://lists.zs64.net/mailman/listinfo/cmucl-help
>
_______________________________________________
cmucl-help mailing list
[email protected]
http://lists.zs64.net/mailman/listinfo/cmucl-help