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