#546 make-pathname merging

Sam Steingold
clisp (525)

Hi all,

I am using clisp-2.47 on Windows (non-Cygwin). I am not sure if this is a feature or a bug!

Regarding the pathname merging behaviour of make-pathname, I expect
the following to be the same, yet they are not:

CL-USER> (merge-pathnames (make-pathname :directory nil) #P"C:\\a\\b\\c.txt")

CL-USER> (make-pathname :directory nil :defaults #P"C:\\a\\b\\c.txt")

I interpret http://www.lispworks.com/documentation/lw51/CLHS/Body/19_bc.htm
to mean that :directory nil means that the pathname-directory is not filled in,
and should be merged with the defaults.

Here is another one,

CL-USER> (merge-pathnames (make-pathname :host nil :device nil
:directory nil)

CL-USER> (make-pathname :host nil :device nil
:directory nil
:defaults #P"C:\\a\\b\\c.txt")

I don't think this matters, but in all the examples above, my

CL-USER> *default-pathname-defaults*

I would appreciate any fixes, or explanations on
alternative interpretation of the CLHS. I don't think this
has been covered in the current docs.

Thanks in advance, and happy hacking.


  • Sam Steingold
    Sam Steingold

    • assigned_to: haible --> sds
    • status: open --> pending-invalid
  • Sam Steingold
    Sam Steingold

    I don't think this is a bug.
    ":directory nil" means _no_ directory component, not an unspecified directory component.
    (merge-pathnames ... foo) is _intentionally_ _not_ the same as (make-pathname ... :defaults foo), and for a very good reason.

    FWIW, sbcl behaves the same way clisp does.

  • Sam Steingold
    Sam Steingold

    This bug report is now marked as "pending"/"invalid".
    This means that we think that the problem you report is not a problem with CLISP.
    Unless you - the reporter - act within 2 weeks, the bug will be permanently closed.
    Sorry about the inconvenience - we hope your silence means that you agree that this is not a bug in CLISP.

    • status: pending-invalid --> closed-invalid
  • This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).