Hello Ben,
> I find that the getusershell module is limited in which file it can
> open (/etc/shells). set_shells_file is a new function that allows the
> user to open a shells file that is located elsewhere.
>
> I've attached the patch rather than providing it inline, because I
> didn't want to gamble with gmail's word-wrapping.
There are three problems with your patch:
1) The 'getusershell' module is meant to be a substitute, for those
platforms that don't have these functions. (See
doc/glibc-functions/getusershell.texi.) This means, on glibc or
Solaris systems, for example, gnulib's lib/getusershell.c is
never compiled. What could/would you want to do so that the
libc function getusershell() looks elsewhere than in /etc/shells?
2) You create a new file "getusershell.h". But glibc has these functions
declared in <unistd.h>, therefore gnulib declares them there as well
(see lib/unistd.in.h). We don't want to have overlapping and possibly
conflicting declarations in two different header files of gnulib.
3) Your set_shells_file function stores a pointer to the passed string
argument. It should make a copy instead. Otherwise code like
{
char buf[100];
strcpy (buf, "/var/etc/shells");
set_shells_file (buf);
}
will make the program crash later.
Bruno
