[arch-dev-public] [signoff] man-pages 3.17-1
shiningxc at gmail.com
Mon Feb 16 03:20:52 EST 2009
On Sun, Jan 25, 2009 at 3:56 PM, Dan McGee <dpmcgee at gmail.com> wrote:
> On Sun, Jan 25, 2009 at 5:04 AM, Xavier <shiningxc at gmail.com> wrote:
>> On Sun, Jan 25, 2009 at 10:31 AM, Andreas Radke <a.radke at arcor.de> wrote:
>>> [andyrtr at 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.
More information about the arch-dev-public