Re: Weird defaulting of pathname-directory?

[Peter S. <pe...@ja...>]

Sam Steingold <sd...@gn...> writes:

> > > > * Peter Seibel <crgre@wninzbaxrl.pbz> [2004-02-11 12:26:21 -0800]:
> >
> >   "Parsing a null string always succeeds, producing a pathname with
> >   all components (except the host) equal to nil."
> 
> in CLISP, :DIRECTORY (:RELATIVE) is the same as :DIRECTORY NIL

Hmmm. Then why have a different value?

> > This defaulting behavior is irksome because binding
> > *DEFAULT-PATHNAME-DEFAULTS* doesn't affect where files are found
> > the way I'd expect it to, given 19.2.3 Merging Pathnames
> >
> >   "Except as explicitly specified otherwise, for functions that
> >   manipulate or inquire about files in the file system, the pathname
> >   argument to such a function is merged with
> >   *default-pathname-defaults* before accessing the file system (as if
> >   by merge-pathnames)."
> 
> what is a specific failure case?

Given that I have files "foo.txt" in both the current working
directory and in /tmp/ and they are different lengths I'd expect the
third element of the list generated by this expression to be the same
as the second, not the first:

  (list
    (with-open-file (in (make-pathname :name "foo" :type "txt")) (file-length in))
    (with-open-file (in (make-pathname :directory '(:absolute "tmp") :name "foo" :type "txt")) (file-length in))
    (let ((*default-pathname-defaults* (make-pathname :directory #p"/tmp/")))
      (with-open-file (in (make-pathname :name "foo" :type "txt")) (file-length in)))) 

  ==> (785704 5 785704)

-Peter

-- 
Peter Seibel                                      pe...@ja...

         Lisp is the red pill. -- John Fraser, comp.lang.lisp