fast-user-switch-applet (and now indicator applet!) does not parse gecos information correctly.

[Tony Shadwick]

I originally submitted this bug for fast-user-switch-applet, and was told that Karmic would be changing it's login system. It appears that the bug also exist in this applet, as well as gnome-screensaver. It could be a gnome bug overall.

I'm using Karmic and likewise-open5, but I suspect any non-local
authentication method would exhibit the same behavior.

Taking my gecos information as an example, the applet only displays my last
name. The reason for this is in the source code, for some unknown reason it
regexes and contrains at a common. Using the following perl script displays
my actual gecos info:

[code]
#!/usr/bin/env perl
use User::pwent qw(:FIELDS);

my $username = shift or die("No username given!");

my $user = getpwnam($username) or die("No such user $username");

print "Username: ".$user->name."\n";
print "Real Name: ".$user->gecos."\n";
print "Home: ".$user->dir."\n";
print "uid: ".$user->uid."\n";
print "gid: ".$user->gid."\n";
print "passwd: ".$user->passwd."\n"
[/code]

Pass it my username (shadwickt) and I get this:

Username: shadwickt
Real Name: Shadwick, Tony
Home: /home/shadwickt
uid: 1283484728
gid: 1283457537
passwd: x

Since the format is lastname, firstname - the applet just shows "Shadwick".
I've confirmed this by downloading the sources and removing the relevant
regex, but unfortunately all of the "nicer" features of the applet go away.
The shutdown/reboot, pidgin status, etc.

I'm not sure why it constrains against a comma, but it is certainly an easy,
albeit cosmetic, fix.

[Ted Gould (ted)]

Plan in the future is to use the glib function g_get_real_name, could
you check to see if that works?

[Robert Collins (lifeless)]

Marking high, as us having a plan implies its been discussed down to ready-to-code level ;)

[Tony Shadwick (numbski+bugs-launchpad-net)]

<jamie hyneman>Well there's yer problem!</jamie hyneman>

[code]
#!/usr/bin/env perl
use strict;
use Glib;
my $name = Glib::get_real_name;
print "$name\n";
[/code]

shadwickt@shadwickt-desk:~/perl-scripts$ ./glib-realname
Shadwick

[Tony Shadwick (numbski+bugs-launchpad-net)]

Well shoot.

http://mail.gnome.org/archives/gtk-devel-list/2004-January/msg00241.html

I know that's 5.5 years old, but it seems that is what's biting me, or rather will be biting me if you use g_get_real_name. I'm getting bitten by a regex at the moment. :P

So - why on earth would this stop at the first comma in get_real_name()? Wouldn't it make more sense to get the whole thing, then do s/,//g?

Not sure whether you would still consider this a bug in Indicator Applet. Since gnome_screensaver does it too - probably because of g_get_real_name's output.

[Robert Collins (lifeless)]

Ok, so we need to switch to g_get_real_name, and separately fix glib.

Tony, care to see if there is an open bug for glib? if there isn't we can open a task on this bug for that.

[Tony Shadwick (numbski+bugs-launchpad-net)]

Just checked within glibc's bugzilla database, and searching for g_get_real_name returns no results. I'll run a few more searches but I'm thinking this is one of those where they think it's a feature not a bug - as that mailing list entry, someone stated:

"Just realized that g_get_real_name() returns the whole
GECOS field rather than just the name part on Unix :-("

Then a dev replied:

"Thats not the case. If you look at the very end of g_get_any_init(),
you'll notice that we only return the part up to the first ,
My patch in 118973 may have mislead you, since I also overlooked that
section when I did the patch."

So now I'm genuinely confused. It's obviously intentially that they regex everything up to the first comma in the GECOS - but what are they expecting to be in that field? I've never seen a situation where anything *but* the person's real name appears in that field. At some point there must have been a reason, but I'm not seeing it. There are other fields for relevant data. Maybe I'm misunderstanding the point of that field in the user's pw entry?

[Tony Shadwick (numbski+bugs-launchpad-net)]

From Linux's own man page on the topic:

GECOS:
This field is optional and only used for informational purposes. Usually, it contains the full user name. GECOS means General Electric Comprehensive Operating System, which has been renamed to GCOS when GE's large systems division was sold to Honeywell. Dennis Ritchie has reported: "Sometimes we sent printer output or batch jobs to the GCOS machine. The gcos field in the password file was a place to stash the information for the $IDENTcard. Not elegant."

So the only thing we should be looking for there is the user's real name. So....I'm at a loss. :P

[Tony Shadwick (numbski+bugs-launchpad-net)]

Sorry for spamming this bug, but I'm really confused now:

http://bugs.debian.org/154269

That's the debian guys saying it's a feature not a bug. It allows "other features of the GECOS field". What "other features"?

Meanwhile, in the perl docs we have this:

http://perldoc.perl.org/User/pwent.html

"Interpretation of the gecos field varies between systems, but traditionally holds 4 comma-separated fields containing the user's full name, office location, work phone number, and home phone number. An & in the gecos field should be replaced by the user's properly capitalized login name ."

So I think what I'm seeing here is a failure to realize when a comma is part of the name formatting convention vs. name, office locations, work phone number, and home phone number. D'oh!

I don't know about you guys, but in the decade or so I've been doing Unix Administration, I've seen the Last Name, First Name convention far more than fname lname,somwhere out there,555-555-1212,555-555-1212. The problem of course is that there's no way of knowing. You've got years of "standard" convention behind the latter way, but the former way is more common currently. So what to do?

I mean if I were in this situation, I could be ugly about it, grab the gecos as a single field, count the commas, and if there's only one, presume then that the whole thing is the "real name". It seems that debian's stock adduser however puts all the extra commas there. This would not impact users from likewise-open5 though, because it never uses that convention. Problem solved.

That's kinda fugly though, and very presumptuous. I don't have a good answer here.

[Robert Collins (lifeless)]

My suggestion is still:
 - fusa uses the right glib function
 - you discuss the right solution with the glib folks.

FWIW I think counting the commas is fairly pragmatic, and with a field
with history as GECOS, you can't really aim for better.

-Rob

[Ted Gould (ted)]

I'm marking this as "wontfix" as we're going to continue to use the Glib functions. Not that it shouldn't be fixed, but there shouldn't be any changes in indicator-applet.

[Tony Shadwick (numbski+bugs-launchpad-net)]

In case anyone comes across this later and wants to follow along:

https://bugzilla.gnome.org/show_bug.cgi?id=627364

[Tony Shadwick (numbski+bugs-launchpad-net)]

Also, this is a bug for glib, NOT glibc. Oops. :P No wonder I got no output of a search over there.

glibc = GNU C Library implementation
glib = Gnome Library