[cmucl-help] ext:unix-namestring issue

[GP lisper]

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 <toy.raymond at gmail.com>
> 
> 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.
> > --
> > Jared C. Davis <jared at cs.utexas.edu>


-- 
A bad day in () is better than a good day in {}