bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: the gnu id and groups procedures


From: Eric Blake
Subject: Re: the gnu id and groups procedures
Date: Sat, 28 Feb 2009 06:09:50 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19) Gecko/20081209 Thunderbird/2.0.0.19 Mnenhy/0.7.6.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Brocci, R. A. on 2/27/2009 7:28 AM:

Hello, R.A.,

> To GNU or the id, groups maintainer(s),
>  
> I propose that the -s/--sort string be an acceptable option to both
> procedures, as in your default id -Gns command in the groups(.sh)
> procedure. Personally, I'm only interested in an ascending (e.g., [Aa]
> to [Zz]) sort, but perhaps this position should be reconsidered.

First, a word on terminology.  Procedures generally implies something at
the programming language level.  Procedures must be coded and compiled
together to form a 'utility' or 'program'.  Coreutils provides pre-built
programs, not procedures - once you have installed id or groups, you don't
have to compile anything further.

Now, on to your request.  Sorry, but adding a --sort option to id or
groups is unlikely to happen.  The power of the Unix philosophy is that
each tool does one thing, and does it well.  The sort utility already
exists to do sorting.

http://www.gnu.org/software/coreutils/manual/coreutils.html#Opening-the-software-toolbox

>  
> Right now, I'm typically piping the groups sysout to [g]awk and using
> its intrinsic asort function.

A bit of an overkill, since you could use sort instead of gawk, but a
prime example of the Unix philosophy at work - you give the unsorted
output from one tool that does one thing well (listing groups) into
another tool that does one thing well (sorting input).

>  
> Finally, our systems personnel tell me that I can belong to a maximum of
> 16 groups, and that things are sometimes flaky if I'm in only 14 or 15.
> Can you offer any insight on the "accuracy/meaningfulness" of  their
> words? (Any speculation on your part would be welcome information.)

This is dependent on your OS.  Not all systems provide the same
limitations, but if there is a limitation, it is enforced by the OS, and
there is nothing coreutils can do about it.

>  
> And, is there a limit on the number of groups that can exist? (I can't
> find anyone here who can give a definitive answer to this question.)

Depending on your OS, yes or no.  Many older systems have a gid_t type
that is only 16 bits wide, so that there are at most 65536 groups
possible.  Newer systems tend to use 32 bits (4 billion) or even 64 bits
(effectively unlimited).

>  
> Note: From a "calibration" point of view, our newest Linux OS (from
> SuSE) has version 5.93 of id and groups,

The latest stable version of coreutils is 7.1; you may want to consider
upgrading, since 5.93 is quite old.  In particular, id 5.93 was a shell
script, and had several implementation bugs as a result, while id 7.1 is a
C program and is more efficient.

> And, our oldest (vendor-specific Unix OS) machines are old enough to not
> support the --help and/or --version options.) 

That's because they are vendor-specific implementations of the id utility;
'id --help' is an extension that only GNU coreutils supports.  However, if
you like the GNU tools, you may be able to install GNU coreutils as a
replacement for the limited-capability vendor tools on those machines.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmpN54ACgkQ84KuGfSFAYChJACdFbjlOmcn6Iwtqlj71DsP7BSh
DaIAoIKfTUVQIJzNoIfhCoPjXisJvOLz
=DLLH
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]