Re: port-filename and path canonicalization

Hi, Andy Wingo writes: > On Tue 20 Apr 2010 18:57, l...@gnu.org (Ludovic Courtès) writes: > >>> 2. I think a fluid is still necessary, because a file being >>> compiled can do an `include' or `include-from-path', or even >>> `open-input-file' in a macro, and all these cases you would want the >>

Re: port-filename and path canonicalization

Hi Ludovic, On Tue 20 Apr 2010 18:57, l...@gnu.org (Ludovic Courtès) writes: >> 2. I think a fluid is still necessary, because a file being >> compiled can do an `include' or `include-from-path', or even >> `open-input-file' in a macro, and all these cases you would want the >> same %file-port-na

Re: port-filename and path canonicalization

() l...@gnu.org (Ludovic Courtès) () Thu, 22 Apr 2010 00:26:43 +0200 > That is, if a file port supports ‘file-port-directory’, then how > to use/restrict the resulting object is left up to higher layers, > where it belongs. I would put it the other way round: if an application wants t

Re: port-filename and path canonicalization

Hi, Thien-Thi Nguyen writes: > That is, if a file port supports ‘file-port-directory’, then how > to use/restrict the resulting object is left up to higher layers, > where it belongs. I would put it the other way round: if an application wants to implement ‘file-port-directory’, then it’s its r

Re: port-filename and path canonicalization

() l...@gnu.org (Ludovic Courtès) () Wed, 21 Apr 2010 10:49:05 +0200 I think open file ports shouldn’t grant any authority beyond access to the open file. Just like an open file descriptor doesn’t convey any authority beyond access to the underlying file (if we omit ‘..’ lookups on a

Re: port-filename and path canonicalization

Hi, Thien-Thi Nguyen writes: > Another idea is to conceptually separate "filename" to be "directory" > and "basename" and have file ports maintain the directory portion as a > file descriptor (or equivalent) internally, exposed through some kind of > opaque handle. I think open file ports shoul

Re: port-filename and path canonicalization

Hi, Andy Wingo writes: > On Tue 20 Apr 2010 01:12, l...@gnu.org (Ludovic Courtès) writes: > >> Andy Wingo writes: >> >>> I recently added a global fluid, %file-port-name-canonicalization, which >>> defaults to #f. But if it's 'absolute, the port name of a file port will >>> be canonicalized to

Re: port-filename and path canonicalization

() Andy Wingo () Tue, 20 Apr 2010 11:42:58 +0200 I'd be happy to have some cleaner solution, though. Do you have any ideas? Another idea is to conceptually separate "filename" to be "directory" and "basename" and have file ports maintain the directory portion as a file descriptor (or equiv

Re: port-filename and path canonicalization

Hi :) On Tue 20 Apr 2010 01:12, l...@gnu.org (Ludovic Courtès) writes: > Andy Wingo writes: > >> I recently added a global fluid, %file-port-name-canonicalization, which >> defaults to #f. But if it's 'absolute, the port name of a file port will >> be canonicalized to the absolute path; or, if i

port-filename and path canonicalization

Hi! Andy Wingo writes: > I recently added a global fluid, %file-port-name-canonicalization, which > defaults to #f. But if it's 'absolute, the port name of a file port will > be canonicalized to the absolute path; or, if it's 'relative, the port > name is the canonical name of the file, relative