to the fact that the /bin/sh set command always sets the exit status to
0, so testing $? will not help discover if getopt found an error if
getopt is used via "set -- `getopt ....`". (POSIX 1003.2 D11 draft says
that the sh set command must return 0 as the exit status.)
I think that POSIX is wrong or that is is not well enough specified to
allow the result of the set to be the exit status of the getopt. But
considering the sequential nature of execution, the set is done last
and is the "last command" and therefore must be the one to set the exit
status. At least there is a work-around for shell scripts.
include <unistd.h> for prototypes, reorder #includes, nuke old library
function declarations
add explicit return types and prototypes for local functions
use STDOUT_FILENO instead of manifest constant
initialize variable for gcc -Wuninitialized (marked as such)
pull global variable declarations and function prototypes into hexdump.h
add #includes where necessary for prototypes
replace index() with strchr(), const-poison static string vars, etc.
Actually there were two bugs:
- Add REG_NOTBOL after the first substitution.
- Handle the rm_so == rm_eo == 0 case, where in a substitution such
as 's/bzzzt/z*/g' the first time z* matches nothing.
The appropriate entry in /etc/group as returned by getgrnam() is
used to determine if 'su root' may be permitted, rather than
checking if membership exists in the result of getgroups().
The following changes were made regarding the behaviour of the special
group for 'su root'
* allow for definition of SUGROUP (defaults to "wheel") to override group name.
* use getgrnam(SUGROUP) instead of getgrgid(0).
* only scan getgrnam(SUGROUP)->gr_mem when checking for group membership.
* be more specific as to why 'su root' failed
NOTE: If a user's primary group is SUGROUP, and they're not a member
of SUGROUP in /etc/group, they will not be able to su.
