On Mon, Jul 7, 2014 at 10:25 AM, Rob Landley r...@landley.net wrote:
Haven't checked this in yet because it needs more testing, but patch is
attached:
GROUP is always toys.optargs[toys.optc-1] so let's move the getgrnam()
before the two if/else cases so it's not duplicated. (Speaking of which,
in the original code getgrnam() with the corresponding error message
gets called twice in a row?)
First question: are we ok hardwiring in the colon-separated /etc/groups
file? (Because I thought android had some magic database instead?) I'm
going to assume that's ok for now...
I got confused by the man page for getgrnam pointing me to man 5 group,
the second of which said that gr_mem is a comma separated list. But in
the first it's a char *array[] which I _assume_ has a null terminator at
the end, but it never SAYS so. (That's what the man page in Ubuntu 12.04
The second one explain about the format of the /etc/group file, where
gr_mem si a comma
separated list. The first one is the structure representation of the same,
as a *array[].
The null termination is not mentioned but is observed to be there.
says, anyway. Maybe it's stale?) That tangent got me to write a
comma_find() function that should at least be useful elsewhere.
The found == -1 part is using xprintf() instead of error_exit() because
it wants to exit with status 0? And to print to stdout instead of
stderr? And while we're at it, removing a user from a group that has no
users in it doesn't produce this message either?
Why do we call getpwnam() at all? Just to confirm it's an actual user?
(Not being there is an error, can it be there and _not_ be a valid user?)
when a user is added to the group, it is validated for its existence, On
deletion
of a user from system it is removed from all the groups it belongs to, may
be due
to this __it__ not being there in case of removal from group is treated as
error.
Ooh, _subtle_: due to xexec() not necessarily doing an actual exec()
each time, we should call setpwent() before our first getpwent() because
it's yet more process state that doesn't necessarily get reset between
calls. (Possibly endpwent() should be part of the toy_init() stuff?) Or
maybe endpwent() is better?
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
