Peter raised an interesting point on IRC - doesn't stat-regular? et al do this? The stat-*? functions all take a file name, call stat, then examine the mode of the result to see if it has the specified type.
Which makes them a bit redundant with directory? et al. How did this come about? It would have made more sense for stat-* to accept a stat-obtained file mode and work on that than a filename that they, themselves, stat. Why the duplication with directory?, symlink? et al? Is anybody actually using stat-*?, or should we change them to operate on file modes? Also, I have developed a few more requests for the posix unit needed to implement Ugarit, my backup system, which I shall implement myself and duly submit code for inclusion if people approve, and nobody points out already exist somewhere: 1) utimes and lutimes, which set the mtime and atime on things (with the l- version operating on, rather than through, symlinks) 2) similarly, l-prefixed versions of chmod and chown, so I can set the attributes of symlinks 3) mknod, so I can restore character and block device files! So far, my backup system backs up files, directories, fifos, symlinks, and block and character device files, and records contents, mtime, ctime, atime, mode, uid, and gid of each, but can only restore files, directories, fifos, and symlinks - and only restore contents, uid, gid, and mode. I've now used up my "2 day" estimate to produce the thing, but I hope to not spend more than a couple more hours tidying up those rough edges and then writing a command-line wrapper around it to do snapshots and restores, then I'll give it a very thorough test on a large filesystem and release it to the public. I plan to see if I can make a tarball that contains all the C sources, even for the eggs I use, so it can be made available to chicken-less people. 388 lines of that are unit tests and testing tools, too ;-) I have 89 lines of local-filesystem storage backend, 63 lines of caching storage backend wrapper, and 622 lines of core algorithms, for a total of 774 lines of code that does real work. The fact that it looks like I'll manage to build a powerful, efficient, reliable backup/archival system in about two days, in under a thousand lines of code, is a testament to the elegance of Scheme! As a case in point, this project has taught me the elegance of fold. I'd always thought that fold looked a bit of a useless function; having read about it, I had a mental note to look it up next time I had to sum the elements of a list or something, until I spotted gdbm- fold in foof's gdbm egg (while writing the cache backend wrapper). That use of the fold 'pattern' to iterate over a database sort of clicked in my head, and I ended up writing my fundamental operators to iterate over large structures in Ugarit as folds, rather than the less elegant for-each I originally had in mind. Fold on! ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/?author=4 _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
