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
