On Fri, Aug 2, 2019 at 5:24 PM Lassi Kortela <xxxxxx@lassi.io> wrote:

- include a procedure to get user info by UID (getpwuid())

- include a procedure to get group info by GID (getgrgid())

Uncontroversial, I think.

- leave out procedure to get user/group info by name (getpwnam())
   Programs should not use Unix usernames for access control.
   Sysadmins should set permissions using usernames interactively,
   but under the hood, the UIDs become the ground truth.

I don't agree there.  Config files should contain names, not numbers (consider crontabs).  Numbers are too easy to get wrong.
Already flushed in my first pass over the scsh manual.
>     Except now that you point it out, we should also include a single
>     direct call that returns the home directory,
> And sets it.  Lots of programs are greatly simplified if they can set
> the working directory.

Oh, wait, I misread "home directory" as "working directory".  No, I think the Right Thing for the home directory is $HOME.  If you shoot yourself in the foot by changing it, so what?
- The current directory is getcwd() / chdir(). I support including both
   of these as straightforward wrappers of those Unix calls.

I'd maybe favor a single file-type procedure that returns a symbol. Ruby
has that (ftype, which returns a string). Easy to check in a case statement.

True, but I don't like accepting or returning symbols: not sure I can say just why.
These comments makes me think timezones should have their own SRFI. A
delightful array of historical, political, notational, scientific and
technical problems rolled into one happy bundle.

I think they'll fit fine into a date/time SRFI that handles TAI (made necessary by R7RS), Posix time, and local civil time.  But no non-Gregorian calendars; that truly *is* a can of worms.  (Mayan, anyone?)
We could have a canonical Scheme library to parse the tzdata files and
convert to S-expressions which Scheme can easily read.

Processing the source files is *hard*, and I'm happy to leave it to zic.   Processing the binaries is hardly even parsing: the format is mostly trivial.
Correct. The ability for users to make new exceptions with arbitrary
errno values could come in handy too,

I don't agree: keep errno for its existing purpose.  We have very rich objects to use as conditions: no reason to pack errors into fixnum space or whatever.  (I've worked with programs that say things like "?0347" when you make a mistake, based on the address at which the error was detected.  They suck.)
It's not really a dark path - starting as root to do some initialization
and then dropping privileges is sound design.

General agreement that chaining and going to Scheme last is the Right Thing.