From: Sam S. <sd...@gn...> - 2004-08-09 20:30:14
|
> * Christophe Rhodes <pf...@pn....hx> [2004-08-09 18:26:12 +0100]: > > Sam Steingold <sd...@gn...> writes: > >>> * Peter Seibel <crgre@wninzbaxrl.pbz> [2004-02-12 13:11:13 -0800]: >>> >>> 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). >> >> Note that this merge requirement means that >> (probe-file open-file-stream) >> can return NIL, which is probably not what most people expect. > > I think *default-pathname-defaults* is part of a contract, or > protocol: entities (libraries or people) setting or binding it to a > silly value deserve to lose. As such, no, people don't expect > (probe-file open-file-stream) to return NIL, but this is just a > reflection of people's expectation that *default-pathname-defaults* is > not set to a silly value. OK. How about DELETE-FILE on open streams? <http://www.lisp.org/HyperSpec/Body/fun_delete-file.html> If the filespec designator is an open stream, then filespec and the file associated with it are affected (if the file system permits), in which case filespec might be closed immediately, and the deletion might be immediate or delayed until filespec is explicitly closed, depending on the requirements of the file system. if *DEFAULT-PATHNAME-DEFAULTS* is set to something silly and the file which is actually to be deleted is different from the argument, then the argument stream should not be closed, right? BTW, even with non-silly *DEFAULT-PATHNAME-DEFAULTS* there are issues: CLISP takes a shortcut of returning T from PROBE-FILE for open file streams (and a similar shortcut for TRUENAME). This is not necessarily valid on UNIX: I believe one _can_ remove a file to which a different process is currently writing: [1]> (setq zz (open "foo" :direction :output)) #<OUTPUT BUFFERED FILE-STREAM CHARACTER #P"foo"> [2]> ^Z [1]+ Stopped clisp $ ls foo 0 foo $ rm foo rm: remove foo (yes/no)? y $ fg clisp [2]> (probe-file zz) #P"/home/sds/foo" [3]> (probe-file "foo") NIL [4]> (close zz) T [5]> (probe-file zz) NIL [6]> note that CLISP will not let one delete a file with an open stream to it: [14]> (setq zz (open "foo" :direction :output)) #<OUTPUT BUFFERED FILE-STREAM CHARACTER #P"foo"> [15]> (delete-file "foo") *** - cannot delete file #P"/home/sds/foo" since there is file stream open to it Break 1 [16]> this appears to be inconsistent: if (DELETE-FILE zz) means (CLOSE zz) + (DELETE-FILE (PATHNAME) zz), then (DELETE-FILE "foo") should mean the same thing. I propose making (DELETE-FILE "foo") silently close ZZ. This would make DELETE-FILE beautifully consistent with the other pathname functions which satisfy the condition (X Y) == (X (PATHNAME Y)) -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> Lisp is a way of life. C is a way of death. |