Matt Gushee scripsit: > (let* ((f (file-open "somefile.txt" (+ open/wronly open/creat open/append))) > (p (open-output-file* f))) > (display <some-text> p) > (close-output-port p))
While this will work, it leaves the port (and the fd) dangling in case of an exception, so it's better to wrap these in dynamic-wind and close both p and f on the way out. > First there is the apparent redundancy of (file-open ... open/append) > vs. (open-output-file ... #:append). The identifier open/append is just bound to an integer: the Posix API is deliberately very close to its C equivalent. It's the same as O_APPEND from <fcntl.h>, and is normally, but not necessarily, 8. > 1. If you create an fd with file-open, then create an > output port by applying open-output-file* to the > resulting fd, you can pass an append argument to > either function, or both; either way, both the fd > and the port are then set to append mode. Correct, because it's really the fd that knows about append mode. > 3. After one output port has been opened and closed, it is an > error to open another output port on the same fd. > > 4. It is an error to write to an fd after the corresponding > port has been closed. That's what you expect in both cases, because closing the port closes the fd. > 5. It is possible to write to a port after the corresponding > fd has been closed, but this does not produce any output. That is surely a bug. > 6. It is possible to open more than one output port on a > single fd, but only the first port produces any output. That's an error that would be hard to catch, I think. A fd is just an integer, and we don't keep around a table of which ports have that fd in them. (Note that not all output ports *have* associated fds; in particular, string ports don't.) > 7. Given an fd F, it is possible to create a second fd G > using duplicate-fileno, then open output ports P and Q, > based on F and G respectively; both ports produce output. Again as expected: the OS manages the interactions between the two fds. > 8. If you pass #:append to one of the output ports opened in > #7, that affects both fds and both ports. The two fds are not really independent: in particular, they share any locks, and it doesn't surprise me too much that they share the same append flag. > #7-9: It seems like generally a bad idea to open more than one fd on a > single file. However, I took a look at the POSIX open() man page, and > as far as I can tell this behavior is permitted. Separate opens (as in #9) maintain separate current positions, which can be handy when you need to read a file sequentially in more than one place at a time. -- We call nothing profound [email protected] that is not wittily expressed. John Cowan --Northrop Frye (improved) _______________________________________________ Chicken-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-users
