Re: [PATCH] user/group completion for dired

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 21 Sep 2011 17:59:14 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: emacs-devel@gnu.org
> 
> On 09/21/2011 12:49 PM, Eli Zaretskii wrote:
> 
> > IMO, the last two sentences are too categorical and too OS-specific.
> > E.g., in the MS-DOS build of Emacs, getpwent and getgrent are
> > available and usable, although MS-DOS is certainly not a Unix system.
> > It should also be possible to write an emulation of these functions
> > for MS-Windows.  And even on Unix systems, I'm not sure the
> > information is always on /etc/passwd.  And the same goes for groups
> > and /etc/groups.
> >
> > So please make the doc strings more vague; it should be enough to say
> > that if this functionality is not supported, the value is nil, or
> > something like that.
> 
> OK. I realize that receiving the list of system users/groups may require
> NSS/LDAP/whatever queries. On GNU/Linux system, it should be possible
> to interface libuser; other systems might have the similar methods,
> but I'm not sure it's worth playing with them just for input completion
> task.

??? My comment was only about the doc string which referenced
/etc/passwd.  AFAIK, no matter where the information resides, the
functions you used will still be able to get at it.  If I'm right,
there's no need to change the code regarding that.

> > We should at least return the single user that is the current user,
> > instead of nil.  Emacs always knows who is the current user, on all
> > supported systems, so there's no need to be so restrictive when
> > getpwent is unavailable.
> 
> OK, I guess it should be Vuser_real_login_name.

Yes, I think so.

> > What happens if the user name includes non-ASCII characters?  If that
> > can happen, we should decode the pw_name string, not just call
> > build_string on the unibyte string we get.  Same issue with the group
> > name.
> 
> Comment around build_string() says it should guess about string data
> and produce multibyte string if necessary.

Why let it guess?  You can do it with 100% certainty in this case,
because the encoding of strings provided by the OS is known -- it's
held in Vlocale_coding_system.  See system_process_attributes for an
example of how to do this.

> On my system (Fedora 15) it was able to decode and represent
> tõendidütles (no ideas what language it is and what does it mean :-)
> as multibyte string.

That's because GNU/Linux systems normally use an encoding that maps
1:1 to the internal Emacs representation of characters.  I'm guessing
that if you look in a debugger on the string you get from getpwent,
you will see it's UTF-8 encoded.  If so, it's sheer luck that it
worked for you.