Conflicting alias for some man pages

Conflicting alias for some man pages

[Helge Kreutzmann]

[-- Attachment #1: Type: text/plain, Size: 2434 bytes --]

Hello Alejandro,
hello Michael,
short description:
Please remove duplicates in the alias (alternative) names of man
pages. (List of known examples at the end).

Long description:

I support Mario in maintaining the translation of manpages
(manpages-l10n) and I'm also the Debian maintainer of manpages-l10n.

Some man pages describe multiple, related commands, functions,
interfaces, …. In the english case, man automatically figures this
out, so that you can call the man page under each name without any
further manual configuration (at least in Debian, where I tried it).

Up to recently, manpages-l10n shipped the translated main man page,
e.g. if
command1.1
contains 

NAME
commmand1, command2 - Description

manpages-l10n shipped e.g. de/man1/command1.1

Under Debian then the following happend:
If I ran
man command1
I saw the German version, however, with
man command2
I got the english version, if it exists, otherwise the German version. 

The maintainer of man requested that I provide explicit symlinks for
these man pages[1], which I implemented for the last upload of
manpages-l10n to Debian.

While doing this, I noticed that some alternative names (aliases)
where used multiple times. This caused link creation to fail (for the
second and further occurences) and should also cause "random"
behaviour for the english pages (as man could select from several
pages).

Could you remove these duplicates in your next upload?

I found the following duplicates, I did not do an extensive search:
===================================================================
rindex - Both in index.3 and in string.3
strncasecmp - Both in strcasecmp.3 and in string.3
strncat - Both in strcat.3 and in string.3
strncmp - Both in strcmp.3 and in string.3
strncpy - Both in strcpy.3 and in string.3
__fpurge - Both in fpurge.3 and in stdio_ext.3
strcspn - Both in strspn.3 and in string.3
strrchr - Both in strchr.3 and in string.3
pselect - Both in select.2 and in select_tut.2

Thanks!

Greetings

            Helge

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020742

-- 
      Dr. Helge Kreutzmann                     debian@helgefjell.de
           Dipl.-Phys.                   http://www.helgefjell.de/debian.php
        64bit GNU powered                     gpg signed mail preferred
           Help keep free software "libre": http://www.ffii.de/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Conflicting alias for some man pages

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 3573 bytes --]

Hi Helge!

On 12/3/22 15:01, Helge Kreutzmann wrote:
> Hello Alejandro,
> hello Michael,
> short description:
> Please remove duplicates in the alias (alternative) names of man
> pages. (List of known examples at the end).
> 
> Long description:
> 
> I support Mario in maintaining the translation of manpages
> (manpages-l10n) and I'm also the Debian maintainer of manpages-l10n.
> 
> Some man pages describe multiple, related commands, functions,
> interfaces, …. In the english case, man automatically figures this
> out, so that you can call the man page under each name without any
> further manual configuration (at least in Debian, where I tried it).
> 
> Up to recently, manpages-l10n shipped the translated main man page,
> e.g. if
> command1.1
> contains
> 
> NAME
> commmand1, command2 - Description
> 
> manpages-l10n shipped e.g. de/man1/command1.1
> 
> Under Debian then the following happend:
> If I ran
> man command1
> I saw the German version, however, with
> man command2
> I got the english version, if it exists, otherwise the German version.
> 
> The maintainer of man requested that I provide explicit symlinks for
> these man pages[1], which I implemented for the last upload of
> manpages-l10n to Debian.
> 
> While doing this, I noticed that some alternative names (aliases)
> where used multiple times. This caused link creation to fail (for the
> second and further occurences) and should also cause "random"
> behaviour for the english pages (as man could select from several
> pages).
> 
> Could you remove these duplicates in your next upload?
> 
> I found the following duplicates, I did not do an extensive search:
> ===================================================================
> rindex - Both in index.3 and in string.3
> strncasecmp - Both in strcasecmp.3 and in string.3
> strncat - Both in strcat.3 and in string.3
> strncmp - Both in strcmp.3 and in string.3
> strncpy - Both in strcpy.3 and in string.3
> __fpurge - Both in fpurge.3 and in stdio_ext.3
> strcspn - Both in strspn.3 and in string.3
> strrchr - Both in strchr.3 and in string.3
> pselect - Both in select.2 and in select_tut.2
> 
> Thanks!
> 
> Greetings
> 
>              Helge
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020742

So, if I understand correctly, specifying the same name in the .SH NAME section 
in more than one page is problematic, right?  It makes sense to me.  I'm a bit 
surprised that this bug hasn't been reported though, but otherwise I'm fine 
fixing it.

I CCed a few people that have a lot more experience than I do, and will probably 
be able to tell if I understood the problem correctly.

So, since we're still on time for the Debian freeze, if you confirm that this is 
the issue and the following fix is correct, I'll implement it and release 
man-pages-6.02 later this month; the solstice seems a proper day for a release, 
celebrating the new Sun.  Thanks for the report!

So, I'll try to find a complete list of duplicate NAMEs, and keep only one of them.


Cheers,

Alex


P.S.: The biggest implication of fixing this before the freeze is that I'll 
release VLA syntax for function parameters, something which I wasn't expecting 
to do so soon.  It seems that Moltke was right[1].  I'm still convinced that 
it's a good change, so let's see how these radical changes are received.  ;)


[1]: <https://lore.kernel.org/linux-man/20221110094033.ptpfsqpvvx2yd5xs@illithid/>

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Conflicting alias for some man pages

[Helge Kreutzmann]

[-- Attachment #1: Type: text/plain, Size: 2209 bytes --]

Hello Alejandro,
On Sat, Dec 03, 2022 at 05:36:20PM +0100, Alejandro Colomar wrote:
> On 12/3/22 15:01, Helge Kreutzmann wrote:

> > Please remove duplicates in the alias (alternative) names of man
> > pages. (List of known examples at the end).
…

> So, if I understand correctly, specifying the same name in the .SH NAME
> section in more than one page is problematic, right?  It makes sense to me.
> I'm a bit surprised that this bug hasn't been reported though, but otherwise
> I'm fine fixing it.

As usually whatis/man is hiding this, probably nobody has noticed (or
bothered reporting).

> I CCed a few people that have a lot more experience than I do, and will
> probably be able to tell if I understood the problem correctly.

Thanks.

> So, since we're still on time for the Debian freeze, if you confirm that
> this is the issue and the following fix is correct, I'll implement it and
> release man-pages-6.02 later this month; the solstice seems a proper day for
> a release, celebrating the new Sun.  Thanks for the report!

Thats great. I put the other Debian maintainer for manpages in CC so that
both are aware as well. If they are able to prepare a release soon
after you did, then the translators could start dealing with [1] which
looks like a big change?

Regarding timing:
There are quite a few fixes noted by the translators in the original
man pages. So it might make sense to report them as well soon? 

Should I report them one by one as I did in the past to this list and
you and Michael Kerrisk in CC? 

(We are not done with all translation updates, but I would simply report
the current issues even if slightly incomplete).

> So, I'll try to find a complete list of duplicate NAMEs, and keep only one of them.

Thank you!

> [1]: <https://lore.kernel.org/linux-man/20221110094033.ptpfsqpvvx2yd5xs@illithid/>

Greetings

         Helge

-- 
      Dr. Helge Kreutzmann                     debian@helgefjell.de
           Dipl.-Phys.                   http://www.helgefjell.de/debian.php
        64bit GNU powered                     gpg signed mail preferred
           Help keep free software "libre": http://www.ffii.de/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Conflicting alias for some man pages

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 2814 bytes --]

Hi Helge,

On 12/3/22 17:51, Helge Kreutzmann wrote:
> Hello Alejandro,
> On Sat, Dec 03, 2022 at 05:36:20PM +0100, Alejandro Colomar wrote:
>> On 12/3/22 15:01, Helge Kreutzmann wrote:
> 
>>> Please remove duplicates in the alias (alternative) names of man
>>> pages. (List of known examples at the end).
> …
> 
>> So, if I understand correctly, specifying the same name in the .SH NAME
>> section in more than one page is problematic, right?  It makes sense to me.
>> I'm a bit surprised that this bug hasn't been reported though, but otherwise
>> I'm fine fixing it.
> 
> As usually whatis/man is hiding this, probably nobody has noticed (or
> bothered reporting).

Yeah, makes sense.

> 
>> I CCed a few people that have a lot more experience than I do, and will
>> probably be able to tell if I understood the problem correctly.
> 
> Thanks.
> 
>> So, since we're still on time for the Debian freeze, if you confirm that
>> this is the issue and the following fix is correct, I'll implement it and
>> release man-pages-6.02 later this month; the solstice seems a proper day for
>> a release, celebrating the new Sun.  Thanks for the report!
> 
> Thats great. I put the other Debian maintainer for manpages in CC so that
> both are aware as well.

Good.

> If they are able to prepare a release soon
> after you did, then the translators could start dealing with [1] which
> looks like a big change?

[1] was only adding syntactic sugar to the code in the SYNOPSIS, so translations 
shouldn't be affected.

> 
> Regarding timing:

Could you please remind me what are the freeze dates and restrictions that 
affect the man-pages?

> There are quite a few fixes noted by the translators in the original
> man pages. So it might make sense to report them as well soon?
> 
> Should I report them one by one as I did in the past to this list and
> you and Michael Kerrisk in CC?

Yes, please, and if there are any old issues that we forgot to address, feel 
free to ping about them.

You can omit Michael from CC if you want[2].

> 
> (We are not done with all translation updates, but I would simply report
> the current issues even if slightly incomplete).

Sure, I'd like to help get as many fixes for bookworm as we can.  I'm not sure 
how much time I'll be able to put in this, but I'll try.

> 
>> So, I'll try to find a complete list of duplicate NAMEs, and keep only one of them.
> 
> Thank you!
> 
>> [1]: <https://lore.kernel.org/linux-man/20221110094033.ptpfsqpvvx2yd5xs@illithid/>
> 
> Greetings
> 
>           Helge

Thank you!

Cheers,

Alex

> 

[2]: 
<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=06e72cb19c74d3b1d661609c698ee26d7b6e4d7e>

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Conflicting alias for some man pages

[Helge Kreutzmann]

[-- Attachment #1: Type: text/plain, Size: 2963 bytes --]

Hello Alejandro,
On Sat, Dec 03, 2022 at 06:03:52PM +0100, Alejandro Colomar wrote:
> > If they are able to prepare a release soon
> On 12/3/22 17:51, Helge Kreutzmann wrote:
> > after you did, then the translators could start dealing with [1] which
> > looks like a big change?
> 
> [1] was only adding syntactic sugar to the code in the SYNOPSIS, so
> translations shouldn't be affected.

That is good to hear. Probably po4a (which we use to manage
translation) will then hide this from us.

> > Regarding timing:
> 
> Could you please remind me what are the freeze dates and restrictions that
> affect the man-pages?

https://lists.debian.org/debian-devel-announce/2022/03/msg00008.html

Essentially this means that starting 2023-03-07 would be the last date
for an upload of manpages without asking for an exception (which
probably would be granted). Also this plan is preliminary and so dates
may shift.

For manpages-l10n the same holds, and we do an update about ~ 1 week
earlier and try to update the translations, so this would go
2023-02-23 (it takes 5 days to migrate from unstable to testing,
maybe longer). 

But this is just a rough estimate and in the past documentation
packages are allowed even later uploads *and* it is not unlikely that
dates do actually shift (i.e. the freeze takes longer).

> > There are quite a few fixes noted by the translators in the original
> > man pages. So it might make sense to report them as well soon?
> > 
> > Should I report them one by one as I did in the past to this list and
> > you and Michael Kerrisk in CC?
> 
> Yes, please, and if there are any old issues that we forgot to address, feel
> free to ping about them.

Thanks. I simply report all outstanding issues in 6.01. If you
disagree with any suggested issue, that's perfectly fine, and if you
tell us (i.e. reply to the mail telling me), then I remove that issue
from the "open" list, so it won't be reported again.

> You can omit Michael from CC if you want[2].

Ok, a pity to hear this. And thanks for taking over.

> > (We are not done with all translation updates, but I would simply report
> > the current issues even if slightly incomplete).
> 
> Sure, I'd like to help get as many fixes for bookworm as we can.  I'm not
> sure how much time I'll be able to put in this, but I'll try.

Ok, I try to report them tomorrow, and most of them should be easy to
fix (we try to explain the necessary fix). We are grateful for any
fix, so don't worry if you cannot resolve them all, we are all
volunteers. Just be aware that this will quite a few e-mails then.

Greetings

           Helge

-- 
      Dr. Helge Kreutzmann                     debian@helgefjell.de
           Dipl.-Phys.                   http://www.helgefjell.de/debian.php
        64bit GNU powered                     gpg signed mail preferred
           Help keep free software "libre": http://www.ffii.de/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Conflicting alias for some man pages

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 4152 bytes --]

Hi Branden, Ingo, and Colin,

On 12/3/22 17:36, Alejandro Colomar wrote:
> Hi Helge!
> 
> On 12/3/22 15:01, Helge Kreutzmann wrote:
>> Hello Alejandro,
>> hello Michael,
>> short description:
>> Please remove duplicates in the alias (alternative) names of man
>> pages. (List of known examples at the end).
>>
>> Long description:
>>
>> I support Mario in maintaining the translation of manpages
>> (manpages-l10n) and I'm also the Debian maintainer of manpages-l10n.
>>
>> Some man pages describe multiple, related commands, functions,
>> interfaces, …. In the english case, man automatically figures this
>> out, so that you can call the man page under each name without any
>> further manual configuration (at least in Debian, where I tried it).
>>
>> Up to recently, manpages-l10n shipped the translated main man page,
>> e.g. if
>> command1.1
>> contains
>>
>> NAME
>> commmand1, command2 - Description
>>
>> manpages-l10n shipped e.g. de/man1/command1.1
>>
>> Under Debian then the following happend:
>> If I ran
>> man command1
>> I saw the German version, however, with
>> man command2
>> I got the english version, if it exists, otherwise the German version.
>>
>> The maintainer of man requested that I provide explicit symlinks for
>> these man pages[1], which I implemented for the last upload of
>> manpages-l10n to Debian.
>>
>> While doing this, I noticed that some alternative names (aliases)
>> where used multiple times. This caused link creation to fail (for the
>> second and further occurences) and should also cause "random"
>> behaviour for the english pages (as man could select from several
>> pages).
>>
>> Could you remove these duplicates in your next upload?
>>
>> I found the following duplicates, I did not do an extensive search:
>> ===================================================================
>> rindex - Both in index.3 and in string.3
>> strncasecmp - Both in strcasecmp.3 and in string.3
>> strncat - Both in strcat.3 and in string.3
>> strncmp - Both in strcmp.3 and in string.3
>> strncpy - Both in strcpy.3 and in string.3
>> __fpurge - Both in fpurge.3 and in stdio_ext.3
>> strcspn - Both in strspn.3 and in string.3
>> strrchr - Both in strchr.3 and in string.3
>> pselect - Both in select.2 and in select_tut.2

Could you please confirm if this is a bug in the Linux man-pages, or is it 
something desirable?  I find it a bit weird that we need to specify a NAME only 
once.  Then whatis(1) will not find the other pages that also talk about an 
interface (of course, ideally, only a page would describe an interface, but we 
know that's not reality).

Cheers,

Alex

>>
>> Thanks!
>>
>> Greetings
>>
>>              Helge
>>
>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020742
> 
> So, if I understand correctly, specifying the same name in the .SH NAME section 
> in more than one page is problematic, right?  It makes sense to me.  I'm a bit 
> surprised that this bug hasn't been reported though, but otherwise I'm fine 
> fixing it.
> 
> I CCed a few people that have a lot more experience than I do, and will probably 
> be able to tell if I understood the problem correctly.
> 
> So, since we're still on time for the Debian freeze, if you confirm that this is 
> the issue and the following fix is correct, I'll implement it and release 
> man-pages-6.02 later this month; the solstice seems a proper day for a release, 
> celebrating the new Sun.  Thanks for the report!
> 
> So, I'll try to find a complete list of duplicate NAMEs, and keep only one of them.
> 
> 
> Cheers,
> 
> Alex
> 
> 
> P.S.: The biggest implication of fixing this before the freeze is that I'll 
> release VLA syntax for function parameters, something which I wasn't expecting 
> to do so soon.  It seems that Moltke was right[1].  I'm still convinced that 
> it's a good change, so let's see how these radical changes are received.  ;)
> 
> 
> [1]: <https://lore.kernel.org/linux-man/20221110094033.ptpfsqpvvx2yd5xs@illithid/>
> 

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Conflicting alias for some man pages

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 4599 bytes --]

Hi Alex,

At 2022-12-09T19:53:44+0100, Alejandro Colomar wrote:
> > > Could you remove these duplicates in your next upload?
> > > 
> > > I found the following duplicates, I did not do an extensive search:
> > > ===================================================================
> > > rindex - Both in index.3 and in string.3
> > > strncasecmp - Both in strcasecmp.3 and in string.3
> > > strncat - Both in strcat.3 and in string.3
> > > strncmp - Both in strcmp.3 and in string.3
> > > strncpy - Both in strcpy.3 and in string.3
> > > __fpurge - Both in fpurge.3 and in stdio_ext.3
> > > strcspn - Both in strspn.3 and in string.3
> > > strrchr - Both in strchr.3 and in string.3
> > > pselect - Both in select.2 and in select_tut.2
> 
> Could you please confirm if this is a bug in the Linux man-pages, or is it
> something desirable?

I don't think it is a bug for multiple pages to have a mandb entry for
the same name.  The man(1) librarian is designed in expectation of that;
we have both printf(1) and printf(3), after all.

> I find it a bit weird that we need to specify a NAME only once.

There is no such need, and it would be impossible to enforce across
projects anyway.

> Then whatis(1) will not find the other pages that also talk
> about an interface (of course, ideally, only a page would describe an
> interface, but we know that's not reality).

apropos(1) and whatis(1) do indeed behave in a way that surprises me on
my Debian system (man-db 2.9.4-2).  I would have expected multiple
results.

What I expected:

$ whatis rindex
rindex (3)           - locate character in string
string (3)           - string operations
[...and maybe others I haven't thought of]

What I got:
rindex (3)           - locate character in string

I am not sure why further matches are being hidden.

"apropos" (synonym: "man -k") searches the page topics _and_ summary
descriptions, while "whatis" (synonym: "man -f") searches only the
topics.

However, given the string(3) page:

.SH NAME
stpcpy, strcasecmp, strcat, strchr, strcmp, strcoll, strcpy, strcspn,
strdup, strfry, strlen, strncat, strncmp, strncpy, strncasecmp, strpbrk,
strrchr, strsep, strspn, strstr, strtok, strxfrm, index, rindex
\- string operations

I don't see why "rindex" isn't treated as a match for "rindex".
"index", "strcoll", and "stpcpy" aren't either, so the position in the
topic list doesn't seem to matter.

I don't see anything ill-formed about the man pages in question, so I
can only assume this is either a man-db bug or an aspect of its behavior
that I don't understand.  But man-db's man(1) page suggests that my
expectations are correct.

--snip--
       man -k printf
           Search the short descriptions and manual page names for the
           keyword  printf  as  regular  expression.   Print  out  any
           matches.  Equivalent to apropos printf.

       man -f smail
           Lookup the manual pages referenced by smail and  print  out
           the   short  descriptions  of  any  found.   Equivalent  to
           whatis smail.
--snip--

Note the plurals.  So I will punt to Colin Watson here.

On another topic, I will stump again for the idea of having separate
strings.h(3) and string.h(3) pages instead of the single string(3) page
we see here.  :)

On yet another topic, the history of strcasecmp() seems incomplete, and
fails to motivate why "strings.h" (note the additional "s") even exists.

NOTES
       The strcasecmp() and strncasecmp() functions first appeared  in
       4.4BSD, where they were declared in <string.h>.  Thus, for rea‐
       sons of historical compatibility, the glibc  <string.h>  header
       file also declares these functions, if the _DEFAULT_SOURCE (or,
       in glibc 2.19 and earlier, _BSD_SOURCE) feature test  macro  is
       defined.

They're older than the above indicates.  strings.h as a _file_ is at
least as old as 4.2BSD (1983),[1] a decade before 4.4BSD.
str{n,}casecmp() came in with 4.3BSD-Tahoe (June 1988).[2]  In
4.3BSD-Reno (June 1989), strings.h became a stump that loaded
<string.h>,[3] where it remained and after which the man-pages history
above picks up the story.

Want a patch?  Feel free to retitle the thread when following up on my
asides.

Regards,
Branden

[1] https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/include/strings.h
[2] https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Tahoe/usr/include/strings.h
[3] https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/include/strings.h

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

str{n,}casecmp(3) and <strings.h> (was: Conflicting alias for some man pages)

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 1596 bytes --]

Hi Branden,

On 12/9/22 21:37, G. Branden Robinson wrote:
> On another topic, I will stump again for the idea of having separate
> strings.h(3) and string.h(3) pages instead of the single string(3) page
> we see here.  :)
> 
> On yet another topic, the history of strcasecmp() seems incomplete, and
> fails to motivate why "strings.h" (note the additional "s") even exists.
> 
> NOTES
>         The strcasecmp() and strncasecmp() functions first appeared  in
>         4.4BSD, where they were declared in <string.h>.  Thus, for rea‐
>         sons of historical compatibility, the glibc  <string.h>  header
>         file also declares these functions, if the _DEFAULT_SOURCE (or,
>         in glibc 2.19 and earlier, _BSD_SOURCE) feature test  macro  is
>         defined.
> 
> They're older than the above indicates.  strings.h as a _file_ is at
> least as old as 4.2BSD (1983),[1] a decade before 4.4BSD.
> str{n,}casecmp() came in with 4.3BSD-Tahoe (June 1988).[2]  In
> 4.3BSD-Reno (June 1989), strings.h became a stump that loaded
> <string.h>,[3] where it remained and after which the man-pages history
> above picks up the story.
> 
> Want a patch?

Sure, patches are always welcome!  =)

Maybe that info would be better in string(3).

> 
> [1] https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/include/strings.h
> [2] https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Tahoe/usr/include/strings.h
> [3] https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/include/strings.h

Cheers,

Alex

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: str{n,}casecmp(3) and <strings.h> (was: Conflicting alias for some man pages)

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 1877 bytes --]



On 12/9/22 21:43, Alejandro Colomar wrote:
> Hi Branden,
> 
> On 12/9/22 21:37, G. Branden Robinson wrote:
>> On another topic, I will stump again for the idea of having separate
>> strings.h(3) and string.h(3) pages instead of the single string(3) page
>> we see here.  :)
>>
>> On yet another topic, the history of strcasecmp() seems incomplete, and
>> fails to motivate why "strings.h" (note the additional "s") even exists.
>>
>> NOTES
>>         The strcasecmp() and strncasecmp() functions first appeared  in
>>         4.4BSD, where they were declared in <string.h>.  Thus, for rea‐
>>         sons of historical compatibility, the glibc  <string.h>  header
>>         file also declares these functions, if the _DEFAULT_SOURCE (or,
>>         in glibc 2.19 and earlier, _BSD_SOURCE) feature test  macro  is
>>         defined.
>>
>> They're older than the above indicates.  strings.h as a _file_ is at
>> least as old as 4.2BSD (1983),[1] a decade before 4.4BSD.
>> str{n,}casecmp() came in with 4.3BSD-Tahoe (June 1988).[2]  In
>> 4.3BSD-Reno (June 1989), strings.h became a stump that loaded
>> <string.h>,[3] where it remained and after which the man-pages history
>> above picks up the story.
>>
>> Want a patch?
> 
> Sure, patches are always welcome!  =)
> 
> Maybe that info would be better in string(3).

Oh, I missed your suggestion about having two separate pages for string.h and 
strings.h.  Please go ahead.  I like it.

> 
>>
>> [1] https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/include/strings.h
>> [2] 
>> https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Tahoe/usr/include/strings.h
>> [3] https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/include/strings.h
> 
> Cheers,
> 
> Alex
> 

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

man-db bugs? (was: Conflicting alias for some man pages)

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 4001 bytes --]

Hi Branden, Colin,

On 12/9/22 21:37, G. Branden Robinson wrote:
> Hi Alex,
> 
> At 2022-12-09T19:53:44+0100, Alejandro Colomar wrote:
>>>> Could you remove these duplicates in your next upload?
>>>>
>>>> I found the following duplicates, I did not do an extensive search:
>>>> ===================================================================
>>>> rindex - Both in index.3 and in string.3
>>>> strncasecmp - Both in strcasecmp.3 and in string.3
>>>> strncat - Both in strcat.3 and in string.3
>>>> strncmp - Both in strcmp.3 and in string.3
>>>> strncpy - Both in strcpy.3 and in string.3
>>>> __fpurge - Both in fpurge.3 and in stdio_ext.3
>>>> strcspn - Both in strspn.3 and in string.3
>>>> strrchr - Both in strchr.3 and in string.3
>>>> pselect - Both in select.2 and in select_tut.2
>>
>> Could you please confirm if this is a bug in the Linux man-pages, or is it
>> something desirable?
> 
> I don't think it is a bug for multiple pages to have a mandb entry for
> the same name.  The man(1) librarian is designed in expectation of that;
> we have both printf(1) and printf(3), after all.
> 
>> I find it a bit weird that we need to specify a NAME only once.
> 
> There is no such need, and it would be impossible to enforce across
> projects anyway.
> 
>> Then whatis(1) will not find the other pages that also talk
>> about an interface (of course, ideally, only a page would describe an
>> interface, but we know that's not reality).
> 
> apropos(1) and whatis(1) do indeed behave in a way that surprises me on
> my Debian system (man-db 2.9.4-2).  I would have expected multiple
> results.
> 
> What I expected:
> 
> $ whatis rindex
> rindex (3)           - locate character in string
> string (3)           - string operations
> [...and maybe others I haven't thought of]
> 
> What I got:
> rindex (3)           - locate character in string
> 
> I am not sure why further matches are being hidden.
> 
> "apropos" (synonym: "man -k") searches the page topics _and_ summary
> descriptions, while "whatis" (synonym: "man -f") searches only the
> topics.
> 
> However, given the string(3) page:
> 
> .SH NAME
> stpcpy, strcasecmp, strcat, strchr, strcmp, strcoll, strcpy, strcspn,
> strdup, strfry, strlen, strncat, strncmp, strncpy, strncasecmp, strpbrk,
> strrchr, strsep, strspn, strstr, strtok, strxfrm, index, rindex
> \- string operations
> 
> I don't see why "rindex" isn't treated as a match for "rindex".
> "index", "strcoll", and "stpcpy" aren't either, so the position in the
> topic list doesn't seem to matter.
> 
> I don't see anything ill-formed about the man pages in question, so I
> can only assume this is either a man-db bug or an aspect of its behavior
> that I don't understand.  But man-db's man(1) page suggests that my
> expectations are correct.
> 
> --snip--
>         man -k printf
>             Search the short descriptions and manual page names for the
>             keyword  printf  as  regular  expression.   Print  out  any
>             matches.  Equivalent to apropos printf.
> 
>         man -f smail
>             Lookup the manual pages referenced by smail and  print  out
>             the   short  descriptions  of  any  found.   Equivalent  to
>             whatis smail.
> --snip--
> 
> Note the plurals.  So I will punt to Colin Watson here.

Hmm, now you say it, I noticed recently that problem too.  Every now and then, I 
try to open a page, and some of the link pages that I had in the past that was 
later moved to a subsection bites me.  Since 'make uninstall' doesn't remove 
pages not present in the source code, I can't remove them (at least not easily). 
  When I try to see all pages available with a name, I can't find them.

I would swear that in the past I could see them all, and it's since last half 
year or year that I only see one page.  There may be a bug in man-db...

Cheers,

Alex

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: man-db bugs? (was: Conflicting alias for some man pages)

[Helge Kreutzmann]

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

Hello Alejandro, hello Branden,
On Fri, Dec 09, 2022 at 09:48:42PM +0100, Alejandro Colomar wrote:
> On 12/9/22 21:37, G. Branden Robinson wrote:
> > What I expected:
> > 
> > $ whatis rindex
> > rindex (3)           - locate character in string
> > string (3)           - string operations
> > [...and maybe others I haven't thought of]
> > 
> > What I got:
> > rindex (3)           - locate character in string

For completeness (when you try to trace this down) I get:
helge@twentytwo:/scr/build/src/DCS$ apropos rindex
index (3)            - findet ein Zeichen in einer Zeichenkette
rindex (3)           - locate character in string
XftCharIndex (3)     - X FreeType interface library

Greetings

           Helge
-- 
      Dr. Helge Kreutzmann                     debian@helgefjell.de
           Dipl.-Phys.                   http://www.helgefjell.de/debian.php
        64bit GNU powered                     gpg signed mail preferred
           Help keep free software "libre": http://www.ffii.de/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Conflicting alias for some man pages

[Helge Kreutzmann]

[-- Attachment #1: Type: text/plain, Size: 3593 bytes --]

Hello Branden,
On Fri, Dec 09, 2022 at 02:37:19PM -0600, G. Branden Robinson wrote:
> At 2022-12-09T19:53:44+0100, Alejandro Colomar wrote:
> > > > Could you remove these duplicates in your next upload?
> > > > 
> > > > I found the following duplicates, I did not do an extensive search:
> > > > ===================================================================
> > > > rindex - Both in index.3 and in string.3
> > > > strncasecmp - Both in strcasecmp.3 and in string.3
> > > > strncat - Both in strcat.3 and in string.3
> > > > strncmp - Both in strcmp.3 and in string.3
> > > > strncpy - Both in strcpy.3 and in string.3
> > > > __fpurge - Both in fpurge.3 and in stdio_ext.3
> > > > strcspn - Both in strspn.3 and in string.3
> > > > strrchr - Both in strchr.3 and in string.3
> > > > pselect - Both in select.2 and in select_tut.2
> > 
> > Could you please confirm if this is a bug in the Linux man-pages, or is it
> > something desirable?
> 
> I don't think it is a bug for multiple pages to have a mandb entry for
> the same name.  The man(1) librarian is designed in expectation of that;
> we have both printf(1) and printf(3), after all.

Ok. The rationale for my request was that the for *localized* system
this does not work in Debian (reliably). It only works if the english
man page is not present, otherwise you get the english version.

For example, for strcasecmp I currently get the german version,
however, for strncasecmp I get the english version.

I reported this to the man-db package in Debian and was told that
this is a bug in manpages-l10n and that I should create symlinks.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020742 for
details.

While doing so, I noticed this problem, because how should I decide if
strncat.3 should point to strcat.3 or string.3? Especially
automatically, because manpages-l10n has a dozen or so languuages with
many thousand man pages.

Currently, the link is set randomly.


> > I find it a bit weird that we need to specify a NAME only once.
> 
> There is no such need, and it would be impossible to enforce across
> projects anyway.

For me I would report that where I notice it, however, I do see you
rationale.

But how should man behave? If you enter
man strncasecmp
should it be the man page for strcasecmp.3 or string.3?

> > Then whatis(1) will not find the other pages that also talk
> > about an interface (of course, ideally, only a page would describe an
> > interface, but we know that's not reality).
> 
> apropos(1) and whatis(1) do indeed behave in a way that surprises me on
> my Debian system (man-db 2.9.4-2).  I would have expected multiple
> results.
> 
> What I expected:
> 
> $ whatis rindex
> rindex (3)           - locate character in string
> string (3)           - string operations
> [...and maybe others I haven't thought of]
> 
> What I got:
> rindex (3)           - locate character in string
> 
> I am not sure why further matches are being hidden.

On my Debian testing system this is (more) correct:

index (3)            - findet ein Zeichen in einer Zeichenkette
rindex (3)           - locate character in string

So maybe something on your system? Is this Debian stable or testing?

Greetings

         Helge
-- 
      Dr. Helge Kreutzmann                     debian@helgefjell.de
           Dipl.-Phys.                   http://www.helgefjell.de/debian.php
        64bit GNU powered                     gpg signed mail preferred
           Help keep free software "libre": http://www.ffii.de/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Conflicting alias for some man pages

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 3807 bytes --]

Hi Helge,

On 12/10/22 08:53, Helge Kreutzmann wrote:
> Hello Branden,
> On Fri, Dec 09, 2022 at 02:37:19PM -0600, G. Branden Robinson wrote:
>> At 2022-12-09T19:53:44+0100, Alejandro Colomar wrote:
>>>>> Could you remove these duplicates in your next upload?
>>>>>
>>>>> I found the following duplicates, I did not do an extensive search:
>>>>> ===================================================================
>>>>> rindex - Both in index.3 and in string.3
>>>>> strncasecmp - Both in strcasecmp.3 and in string.3
>>>>> strncat - Both in strcat.3 and in string.3
>>>>> strncmp - Both in strcmp.3 and in string.3
>>>>> strncpy - Both in strcpy.3 and in string.3
>>>>> __fpurge - Both in fpurge.3 and in stdio_ext.3
>>>>> strcspn - Both in strspn.3 and in string.3
>>>>> strrchr - Both in strchr.3 and in string.3
>>>>> pselect - Both in select.2 and in select_tut.2
>>>
>>> Could you please confirm if this is a bug in the Linux man-pages, or is it
>>> something desirable?
>>
>> I don't think it is a bug for multiple pages to have a mandb entry for
>> the same name.  The man(1) librarian is designed in expectation of that;
>> we have both printf(1) and printf(3), after all.
> 
> Ok. The rationale for my request was that the for *localized* system
> this does not work in Debian (reliably). It only works if the english
> man page is not present, otherwise you get the english version.
> 
> For example, for strcasecmp I currently get the german version,
> however, for strncasecmp I get the english version.
> 
> I reported this to the man-db package in Debian and was told that
> this is a bug in manpages-l10n and that I should create symlinks.
> 
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020742 for
> details.
> 
> While doing so, I noticed this problem, because how should I decide if
> strncat.3 should point to strcat.3 or string.3? Especially
> automatically, because manpages-l10n has a dozen or so languuages with
> many thousand man pages.
> 
> Currently, the link is set randomly.
> 
> 
>>> I find it a bit weird that we need to specify a NAME only once.
>>
>> There is no such need, and it would be impossible to enforce across
>> projects anyway.
> 
> For me I would report that where I notice it, however, I do see you
> rationale.
> 
> But how should man behave? If you enter
> man strncasecmp
> should it be the man page for strcasecmp.3 or string.3?

The answer is here:

alx@asus5775:~/src/linux/man-pages/man-pages/main$ cat ./man3/strncasecmp.3
.so man3/strcasecmp.3


I don't know how the man pages are preprocessed before they arrive to you, so in 
that processing might be the problem.  Maybe some information is being lost in 
the process.

Cheers,

Alex

> 
>>> Then whatis(1) will not find the other pages that also talk
>>> about an interface (of course, ideally, only a page would describe an
>>> interface, but we know that's not reality).
>>
>> apropos(1) and whatis(1) do indeed behave in a way that surprises me on
>> my Debian system (man-db 2.9.4-2).  I would have expected multiple
>> results.
>>
>> What I expected:
>>
>> $ whatis rindex
>> rindex (3)           - locate character in string
>> string (3)           - string operations
>> [...and maybe others I haven't thought of]
>>
>> What I got:
>> rindex (3)           - locate character in string
>>
>> I am not sure why further matches are being hidden.
> 
> On my Debian testing system this is (more) correct:
> 
> index (3)            - findet ein Zeichen in einer Zeichenkette
> rindex (3)           - locate character in string
> 
> So maybe something on your system? Is this Debian stable or testing?
> 
> Greetings
> 
>           Helge

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Conflicting alias for some man pages

[Helge Kreutzmann]

[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]

Hello Alejandro,
On Sun, Dec 11, 2022 at 02:52:59PM +0100, Alejandro Colomar wrote:
> On 12/10/22 08:53, Helge Kreutzmann wrote:
> > But how should man behave? If you enter
> > man strncasecmp
> > should it be the man page for strcasecmp.3 or string.3?
> 
> The answer is here:
> 
> alx@asus5775:~/src/linux/man-pages/man-pages/main$ cat ./man3/strncasecmp.3
> .so man3/strcasecmp.3
> 
> 
> I don't know how the man pages are preprocessed before they arrive to you,
> so in that processing might be the problem.  Maybe some information is being
> lost in the process.

Thanks for the explanation.

No, currently we dont't have these in our archives. But I see some
vagbue mentioning in our scripts, so I will have a look.

Greetings

           Helge
-- 
      Dr. Helge Kreutzmann                     debian@helgefjell.de
           Dipl.-Phys.                   http://www.helgefjell.de/debian.php
        64bit GNU powered                     gpg signed mail preferred
           Help keep free software "libre": http://www.ffii.de/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]