Email list hosting service & mailing list manager


Re: process-group, and why only filename type arg for set-file-mode, set-file-owner and set-file-group Lassi Kortela 27 Jul 2020 06:10 UTC

> For making Scheme interface align with chown(2), I'd like to push it
> gently unless the current set-file-owner/set-file-group split has a
> convincing reason.

+1, I also prefer it slightly.

>     I have no informed opinion on it, have never worked with process
>     groups.  It would seem to be gratuitous after we decided to punt to
>     ProcessesCowan, but per you 11 months ago:
>     https://srfi-email.schemers.org/srfi-170/msg/11988851/
>
>>     I want to bring back the `parent-pid` and `process-group`
>>     accessors as well as adding `session-id`.  They don't fit well
>>     into my ProcessesCowan proposal, but they are harmless and trivial
>>     to implement.
>
>     Really, *really* trivial, in Chibi Scheme: "(define-c int
>     (process-group getpgrp) ())" in a stub file, just like parent-pid
>     and pid.  session-id didn't make the cut for some reason, or perhaps
>     in all this excitement was lost track of.

getsid() -- get session ID -- is equally trivial:
<https://pubs.opengroup.org/onlinepubs/9699919799/functions/getsid.html>

setsid() is not hard either:
<https://pubs.opengroup.org/onlinepubs/9699919799/functions/setsid.html>

These could go into 170, or into Harold's new terminal SRFI.

>     In answer to Shiro's previous query of why set-file-mode,
>     set-file-owner and set-file-group only take a file name while
>     file-info for example can also take a port, looking at the
>     discussion it was from our deciding to use the Pareto "80/20"
>     principle to simplify the burden on an implementor as much as we
>     thought was reasonable.  Look for the subject substring "Making
>     SRFI-170 less of a monster", and John on their not meeting that
>     burden here: https://srfi-email.schemers.org/srfi-170/msg/11918491/,
>     "These were file-only for a looooong time before their fd
>     equivalents were introduced, and 'when in doubt, leave it out'."

This is a good principle in general, but POSIX provides calls like
fchown() and fchmod() which deliberately have the same API as the
counterparts that take pathnames, except for the first arg. Hence it's
not a big divergence.

I'm not sure about how to do these in Windows. Something about security
descriptors? The Windows security stuff seems quite complex.