[cmucl-help] ext:unix-namestring issue

[Jared C. Davis]

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/