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

Reply via email to