Comment 1:

The os/user package has a complex conditional Makefile.
include ../../../Make.inc
TARG=os/user
GOFILES=\
    user.go\
ifeq ($(CGO_ENABLED),1)
CGOFILES_linux=\
    lookup_unix.go
CGOFILES_freebsd=\
    lookup_unix.go
CGOFILES_darwin=\
    lookup_unix.go
endif
ifneq ($(CGOFILES_$(GOOS)),)
CGOFILES+=$(CGOFILES_$(GOOS))
else
GOFILES+=lookup_stubs.go
endif
include ../../../Make.pkg

Comment 2:

Not for long.  Makefiles will be removed.
But what does that have to do with this bug?

Comment 3:

Marking as Later because it would not be a backwards-incompatible change, even though it
may happen for Go 1.

Labels changed: added priority-later, removed priority-triage.

Comment 4:

Labels changed: added go1.1maybe.

Comment 5:

So, would LookupGroup return some struct about the user's main group? A list of groups
the user belongs to? Is it an api for getting information about a specific group?

Comment 6:

By analogy with LookupUser, LookupGroup should return information about a specific group
by name.  There should probably be a Group type, with the group name, group ID, and a
user list.  LookupGroupId would take a group ID and return the group information.
We should also have a function to return the list of groups for a user.
This would have to work for Windows also.  I have no idea what groups look like on
Windows.

Comment 7:

Labels changed: added suggested.

Owner changed to ---.

Comment 8:

I've been looking through the code and modeling the group datastructure. AFAIK there's
no sane way to get this info w/o cgo, right?
I haven't really figured out the windows side of this API quite yet.

Comment 9:

Correct. You'll want to use cgo, just like the user lookup functions.

Comment 10:

Awesome, I'll plan on working on a CL this week then.

Comment 11:

Labels changed: removed go1.1maybe.

Comment 12:

CL at https://golang.org/cl/4589049/ but for after Go 1.1.

Comment 13:

[The time for maybe has passed.]

Comment 14:

Labels changed: added go1.2maybe.

Comment 15:

Labels changed: added feature.

Comment 16:

Is this going anywhere?

Comment 17:

Status changed to Started.

Comment 18:

Not for this round I guess.

Labels changed: added go1.3maybe, removed go1.2maybe.

Comment 19:

Also: https://golang.org/cl/13454043

Comment 20:

Brad, lets leave it for after go1.2, so we can try to actually implement it on windows.
We might discover the interface is not suitable.
Alex

Comment 21:

Of course. This isn't for Go 1.2.

Comment 22:

Labels changed: removed feature.

Comment 23:

Labels changed: added release-none, removed go1.3maybe.

Comment 24:

Labels changed: added repo-main.

Is there still interest in adding this? I was surprised to find it missing. I could try writing it.

It's mostly written already; I'm not sure why it never made it in. See the CLs linked above.

@zombiezen, do you want to usher it through?

I'll take a look tomorrow. I'll reach out to the CL author for permission
to clone it.

On Tue, Jan 19, 2016 at 9:53 PM Brad Fitzpatrick notifications@github.com
wrote:

@zombiezen https://github.com/zombiezen, do you want to usher it
through?

—
Reply to this email directly or view it on GitHub
#2617 (comment).

That'll save me trying to consolidate the ~20 scattered copies of @andrenth's code down to one stable dependency, @zombiezen. All luck to you.

I have the CL mostly ready, but when I go to test locally, the size of the group is too large in memory. Turns out that _SC_GETGR_R_SIZE_MAX is not a maximum, but a suggested size for the buffer, and proper implementations need to do retries.

CL https://golang.org/cl/19235 mentions this issue.

Has this been implemented? I don't see it in the doc for os/user

@cgkades it will be in 1.7, which is not yet released. You can see the upcoming docs here:

https://tip.golang.org/pkg/os/user/#LookupGroup