bug-coreutils
[Top][All Lists]
Advanced

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

Re: getpwnam


From: Bruce Korb
Subject: Re: getpwnam
Date: Tue, 30 Dec 2003 10:38:04 -0800

Bob Proulx wrote:
> 
> Bruce Korb wrote:
> > Attached is my effort to get getpwnam to use the coreutils
> > infrastructure.  These are the hand edited files:
> 
> [I posted this to the list before so apologies to those who saw it
> previously.  But not getting an answer I will be more persistent.  :-)]
> 
> How would this relate to the existing 'getent' from glibc?  There
> appears to be a lot of overlap.  But getent seems to be more general.
> 
>   getent passwd bob
>   bob:x:1000:1000:Bob Proulx,,,:/home/bob:/bin/bash

1.  you cannot get it by user id, you must supply the login name.
    Thus, you cannot use it within a script trying to figure out
    the full name of the current user.   (This was the original
    problem that lead me down this path:

        usrid=`id | sed 's, .*,,;s,),,;s,^.*(,,'`
        usrnm=`egrep "^${usrid}:" /etc/passwd | awk ....`

    you get the idea:  grotesquely ugly.

2.  you must still know that the comment is the 5th field, for example
    and parse the line.  Thus, getent isn't any better than:
       egrep '^bob:' /etc/passwd
    which is simple enough to not warrant a "getent" program.

> Of course other systems like HP-UX don't have glibc and also don't
> have 'getent' either because of this.  Personally I would rather see
> getent in coreutils so that it would be available on all of the
> platforms that coreutils is available.  And of course a getpwnam in
> coreutils would be nice for similar reasons.
> 
> Note that I am not opposed to adding something like this to
> coreutils.  I just want to know why we are adding it when the
> functionality already exists and is widely available.

The functionality doesn't exist.  However, "getent" might be a reasonable
vehicle for the functionality, but it would have to be enhanced by being
able to get it to print a specific field from a particular database,
instead of the entire entry.  As long as you're at it, it could as well
be enhanced by allowing for selecting with regex-es on alternate keys, too.
Still and all, I like the idea of having programs that back up lib calls
with fairly obvious options and arguments.

Cheers, Bruce




reply via email to

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