From: Sam S. <sd...@gn...> - 2004-01-12 18:33:24
|
> * Bruno Haible <oe...@py...t> [2004-01-12 19:05:19 +0100]: > Sam wrote: > > At the root, this is a problem in Linux itself: The /proc "files" are > labelled as regular files, but don't support lseek() and the like. At > some point in the past, I had some of them labelled as "pipes". Then > clisp would run fine on them but "less" doesn't want to show their > contents. So my patch was backed out. I guess less is more widely used than clisp. otoh, I don't see why less cannot read from named pipes: it can read from a shell pipe, like "ls|less". > An idea for clisp would be to use a different code for unbuffered > streams when the first lseek() call reports a failure. actually, if clisp can handle named pipes (as you claim above), if might make sense to change the type of the stream from simple file to named pipe if the first call to lseek() fails. >> I suggest that CLISP delegates the file system access to the OS as >> much as possible (and in a transparent way!) >> I.e., right now, >> (OPEN "/foo/bar/bar/zot") >> results in 4 system calls (one for each path element) while, IMO, it >> should do 2 system calls: realpath() and open(). > > realpath() is not a system call. <http://www.opengroup.org/onlinepubs/007904975/functions/realpath.html> OK, it's in libc, not in the kernel. is that what you meant? -- 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> Single tasking: Just Say No. |