> From: Lassi Kortela <xxxxxx@lassi.io> > Date: Monday, August 26, 2019 10:18 AM > Thank you to both of you for the continued hard work on the drafts! You're very welcome! It's rewarding work. >> I renamed `tty?` to `terminal?`. As of now, there are no instances >> of "tty" in the SRFI except in the command `stty` and the names of >> Posix functions. Unavoidably there's also errno/notty, which I found when checking my Chibi Scheme define-library exports list. >> In DEC OSes, device names couldn't be more than three letters long, >> but that's long dead. Much more likely due to the extreme premium attached to typing and printing even a single character using a 110 baud Teletype Model 33 KSR. Slow, and the keys required a lot of force. See for example the ed text editor, which had exactly one error message, "?". > Good call. > [ Windows, etc. ] > Minor nits: > [ "fifos" -> "named pipes" on which I no strong opinion. ] > * (BTW: we don't have a pipe() procedure?) It's only? useful in the context of forking, which is beyond the remit of this basic POSIX SRFI? > * The following stat fields are obscure and rarely used: > (file-info:device file-info) → integer (procedure) > (file-info:inode file-info) → integer (procedure) > (file-info:nlinks file-info) → integer (procedure) > (file-info:rdev file-info) → integer (procedure) > (file-info:blksize file-info) → integer (procedure) > (file-info:blocks file-info) → integer (procedure) > device and inode are good to have for file uniqueness checking, but > should we instead provide an OS-dependent uniqueness identifier > (which on Unix can be a (device . inode) cons cell)? See below for one way device is useful, a change signals you've crossed a mount boundry, which can be useful for anything including a backup that doesn't want to do that, or limiting the search space for all hard links to an inode. Plus this is a POSIX SRFI, I believe raw versions of struct fields should always be supplied even if we add smarter versions like user-info:parsed-full-name on top of the raw pw_gecos field that's named user-info:full-name. > nlinks is the number of hard links. Harold, do you have a use case > for this in your backup program? I think it's generally useful, for example if you absolutely, positively want to kill the storage (inode) of a file, you need to get the link count down to 1 before your final unlink system call (modulo the file being opened by a program, one of the biggest advantages UNIX has over Windows). It and device and inode are absolutely required to avoid backing up the same inode multiple times, and to write data to the backup so a restore can Do The Right Thing. > rdev is the device type. What does that mean - are these device > numbers used internally by the kernel? Per http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html It's "Device ID (if file is character or block special).", your guess is correct. It was added when blksize and blocks were added, all three are XSI extensions that I think have been universally added. > blksize and blocks are nowadays-obscure details of the file system > implementation. The most likely use for these is using them by > accident instead of file-info:size. blksize is useful for setting buffer sizes, but blocks is essential, it tells you how much space a file is really taking up, it ignores holes, and rounds up to whatever is the base device block size. My thought is that if you're going to add blocksize, you might as well add all three, in the "struct members are the most trivial things we can add to the API" principle. > * directory-files -- would be clearer to call it "directory-names" > for two reasons: 1) it's not clear whether it returns full paths or > only the basename parts; "names" emphasizes that it's the basenames > only. 2) "files" suggests regular files only; this is a meaningful > distinction in some Common Lisp implementations. "names" is clearer > that it returns all names in the directory, not just regular files. This conflicts with the desire to keep as many procedure names the same as scsh as possible, but your arguments to rename it are strong. > [ "dotfiles?" in directory-files, which I have no opinion on. ] > * Could 'delete-directory' be called 'delete-empty-directory' for > extra clarity? Heh, yes, that's certainly an obnoxious but vital safety feature when at a shell level, as scsh was in part intended to provide. Although something more like delete-directory-if-empty would be more clear. In any case, another deviation from scsh's name. > A 'delete-directory-tree' procedure would be useful in a higher > level library. When both exist, the distinction is not obvious > unless the names are explicit. And extremely dangerous. My hardcore backup posture started with my using a DECtape to get general experience in that sort of thing, just before I learned the -rf arguments to rm. > * call-with-temporary-filename has "temporary" in the name; all the > other tempfile definitions just say "temp". create-temp-file is inherited from scsh, temp-file-prefix is the SRFI-170 version of scsh's fluid variable *temp-file-template*, call-with-temporary-filename is a SRFI-170 original. > [ (read-symlink fname [override?]) ] - Harold
