Desmond is right that there's a bug, because I was calling subpathname on the output of some getenv calls that might return paths without a trailing /. Douglas is right that it's ugly to have subpathname call ensure-directory-pathname. So I introduced an internal function subpathname* that combines the two. The bug should be fixed in 2.018.18.

Sorry about the bug and thanks for the report!

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org

On Mon, Nov 21, 2011 at 06:34, Douglas Crosher dtc-asdf@scieneer.com wrote:

Hi Des,

I suggest leaving 'subpathname as it is and correcting the directory to include the slash.  Is there any reason this would not work?

The function 'ensure-directory-pathname looks like are real hack, appending a file-namestring onto a directory list passed to 'make-pathname.  Namestrings are designed for parsing to pathnames, and are not intended to be used like this - this will break in subtle ways, such a namestrings with escaped characters, and there is the potential for character case issues.

Perhaps 'ensure-directory-pathname should just signal an error if the pathname includes a name, type or version.

Regards Douglas Crosher

On 21/11/11 20:47, Desmond O. Chang wrote:

...

Hi,

Please fix debbugs #647544:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647544#10

I reported it on debbugs but actually it's from upstream.

In brief, what's the return value of this?

(subpathname "/usr/share" "common-lisp/source/")

I think it should be "/usr/share/common-lisp/source/", not "/usr/common-lisp/source/".

Thanks, Des