unarchive 9987
stop
On 05/28/2013 10:10 AM, Ondrej Oprala wrote:
> Hi,
> I'd like to propose a patch based on
> http://lists.gnu.org/archive/html/bug-coreutils/2011-11/msg00024.html .
> The -{0,1} option is only enabled for some option combinations (as discussed
> in above link)
> although I have some doubts about the usefulness of groups -0|-1 without any
> other arguments;
> on the other hand, changing the delims for the "USERNAME_1:
> group_1...group_n" output is IMHO very weird.
> However, maybe we could only print the "USERNAME: " part if more than one
> username is specified as an argument.
> Or does "id USERNAME -Gn" suffice in this case? What do you think?
Thanks for following this up.
> diff --git a/src/groups.c b/src/groups.c
> index 53332d5..8f5a714 100644
> if (optind == argc)
> {
> }
> else
> {
> + if (nullterm || one_per_line)
> + error (EXIT_FAILURE, 0, _("delimiter modififers cannot be "
> + "combined with other arguments"));
So what you're saying here is that when groups(1) goes into
its alternate display mode when multiple users are specified,
then discount specified delimiters in this case.
I'd concur with that, since this mode would mainly be
for human rather than programmatic consumption.
So all we have to consider is `groups [$USER]` and 'id -Gn`.
I notice that groups goes into "$user: $group1...$groupn" mode
even if a single user is specified. I notice solaris or FreeBSD
do not do that. As part of this as a separate patch, I'd be
inclined to behave like solaris/BSD here so that programmatic
access to groups for all users would be improved.
As for which of -01z to use.
Do we really need -1?
That could be trivially achieved with tr '\0' '\n'
Given that this is to aid programmatic access to group names,
I'd be inclined to not support -1
As for -0 vs -z:
-0, --null: du, env, printenv
-z, --zero: basename, dirname, join, sort, uniq, readlink, realpath, shuf
So for consistency I'd use -z, --zero (adding the long option too).
thanks,
Pádraig.
