On Sun, Jan 25, 2009 at 3:56 PM, Dan McGee <firstname.lastname@example.org> wrote:
> On Sun, Jan 25, 2009 at 5:04 AM, Xavier <email@example.com> wrote:
>> On Sun, Jan 25, 2009 at 10:31 AM, Andreas Radke <firstname.lastname@example.org> wrote:
>>> [andyrtr@laptop64 ~]$ locate geteuid
>>> your command is broken in all man-pages versions since 3.00 - are you
>>> sure anything else but "man geteuid"(works here) is wanted and needed?
> I chose this one randomly and it happened to blow up on me, so sorry
> for the lucky smoke test.
> Not so much needed as "if we install something, it shouldn't be
> broken". But with Xavier's comment below about them not all being
>> Probably not, but this issue is quite weird, there are many others *32
>> man pages that are just simple links, and they all work fine.
>> $ zcat /usr/share/man/man2/geteuid32.2.gz
>> .so man2/geteuid.2
>> $ zcat /usr/share/man/man2/getgid32.2.gz
>> .so man2/getgid.2
>> $ zcat /usr/share/man/man2/getgroups32.2.gz
>> .so man2/getgroups.2
>> Yet, only geteuid32 is broken. Very weird.
> That is quite odd. What is different about this one that it fails to
> link correctly?
Oh I am so stupid, I finally found what the difference is. It breaks
when we have more than 1-level symlink.
lstat64 -> lstat -> stat
geteuid32 -> geteuid -> getuid
Now it doesn't look so odd anymore, good
And thanks, you just gave me another argument for pushing for man-db :
It works perfectly fine with man-db.
What's up with a tool for reading man pages that does not even support
their compression? Sounds unbelievable.