Re: [osicat-devel] bug in UNMERGE-PATHNAMES when called with #P
What should it do when it gets a relative pathname? E.g.: #p"foo/bar/".
I think #p"/" should not be treated fundamentally different to #p"foo/". E.g.: (unmerge-pathnames #p"foo/bar/baz" #p"foo/bar/") => #p"baz" (unmerge-pathnames #p"/foo/bar/baz" #p"foo/bar/") => #p"/foo/bar/baz"
On Fri, Jun 29, 2012 at 4:24 PM, <max@mr.gy> wrote:
What should it do when it gets a relative pathname? E.g.: #p"foo/bar/".
I think #p"/" should not be treated fundamentally different to #p"foo/".
E.g.: (unmerge-pathnames #p"foo/bar/baz" #p"foo/bar/") => #p"baz" (unmerge-pathnames #p"/foo/bar/baz" #p"foo/bar/") => #p"/foo/bar/baz"
So, what you're proposing is that mixing relative pathnames with absolute pathnames turns UNMERGE-PATHNAMES into a no-op. (Your patch only dealt with one such case, where the second pathname was the empty relative pathname #p"".) It seems cleaner to refuse mixing absolute and relative pathnames. Do you have a use case where mixing the two makes sense? -- Luís Oliveira http://r42.eu/~luis/
participants (2)
-
Luís Oliveira -
max＠mr.gy