The umask system call which is equivalent to this SRFI's set-umask returns the previous umask (setting and resetting the umask to a saved copy is the only way to find out what it currently is...). Any reason to not change the undefined return of set-umask to return the old umask, except for scsh returning a #{Unspecific} value, which can be noted in Implementation?
LGTM.
Hmmm, Chibi Scheme defaults creating directories and symbolic links with permission bits #o775 instead of the SRFI's #o777, not defaulting to world writable would be a very good idea. Ditto fifoes, except #o664 is its appropriate set of permission bits.
Makes sense. scsh in this way dates back to a friendlier era.
Will no longer needed once I implement both in Chibi Scheme (due to stealing copying with full attribution from filesystem.stub, should be trivial as soon as I do the general SRFI's error system), I suggest renaming create-symlink to create-symbolic-link.
"Symlink" is a perfectly normal term. I know Chibi uses symbolic-link, but I don't see much point in changing it in the SRFI. That opens the can of worms labeled "Whose procedure names should we use?", which I very much don't want.
An operation missing from both R7RS and the SRFI that's in Chibi Scheme's filesystem library that I think should be added because of it's trivial implementation is rename-file. This also gives us the opportunity if we so desire to rename chdir -> change-directory and cwd -> change-working-directory.
I flushed it accidentally. I restored it from the scsh manual and sent you a PR.
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgWhen I'm stuck in something boring where reading would be impossible or
rude, I often set up math problems for myself and solve them as a way
to pass the time. --John Jenkins