Date: Monday, July 08, 2019 7:13 AM
Note that where I say "it would be nice to add/change/whatever" something, if you agree I'll be happy to provide sample text.
Would you be willing to either:
a) fork my repo, make the changes, and send a pull request, or
Will do.
b) make the changes and email me the revision?
That would be very helpful.
In the below, silence gives consent.
I appreciate your cleaning this up. There is no documentation of what changes were made between scsh 0.6.2 and 0.7, so I worked solely from the 0.6.2 documentation, but I did what little experimenting I did using 0.7.
Why don't I fork that scsh repo (to where, if not my personal GitHub account?), and fix up the README, so you can add a link to it somewhere? Perhaps fix those 2 undefined symbol warnings while I'm at it, making an even less official 0.7.1 or whatever.
Should the type(s) of perms be specified, and while this increases implementation complexity, should the non-octal symbolic string variety be a required option?
No, I don't think it should be required.
While I agree in limiting the remit of this SRFI to not take symbolic permission mode strings, the same can be achieved by simple Scheme procedures that could be supplied to library developers. One to convert a string to an octal mode, one or two to change the mode by calling file-info and set-file-mode to add and/or subtract modes in the style of chmod.
Or should this SRFI and e.g. the advanced file operations one stay at the UNIX man level 2 of system calls, and one or more SRFIs be added to access level 3 library functions and include things like the above convenience procedures? Which may be akin to BSD's
getmode and
setmod:
https://man.openbsd.org/setmode.3 Come to think of it, there's lots of good BSD stuff that either AT&T or Linux failed to adopt, except perhaps in compatibility libraries.
- Harold