Re: [PATCH] execveat.2: srcfix

Alejandro Colomar (man-pages)
2021-01-04T12:59:59Z

Hi Michael,

On 1/3/21 1:11 PM, Michael Kerrisk (man-pages) wrote:
> Hi Alex,
>
> On 1/2/21 10:40 PM, Alejandro Colomar (man-pages) wrote:
>> Hi Michael,
>>
>> I read everything this time ;)
>>
>
> :-)
>
> [...]
>
>>>>>> Still I didn't read past that :)
>>>>
>>>> Later I'll have a look past there :)
>>>
>>> That would be great!
>>
>> adjtimex.2: compact
>
> I decided against. It feels too crowded.

Okay

>
>> getpeername.2: 78-col
>
> It *is* with 78-col?

Yes it is. I may have seen a phantom :)

>
>> msgop.2: compact
>
> It feels a bit too crowded.

Okay.
>
>> circleq.3, list.3, slist.3, tailq.3, stailq.3: group?
>
> I've taken a shot at that. You may have improvements to
> suggest, or even reorderings to suggest (as patches).

I'd group _FIRST, _LAST, _NEXT, _PREV; or at least _FIRST with _LAST.
And I don't know which ordering to use within that group.
Any ideas? FLNP? FNPL? FPNL? FL NP? NP FL?
To be consistent with the ordering you used for _INSERT_,
we could use 'NP FL',
and put those 2 groups after the 2 _INSERT_ groups.

>> exec.3: consistency with commas; execvpe can be joined
> Done; done

wsfix: g/char */s//char */

>
>> rtnetlink.3: group or compact; 78-col
>
> Group. But I don't see the 78-col problem?

Me neither :/

>> sigpause.3: compact
>
> I prefer not. The APIs have the same name. A bit of space emphasizes that
> they are different, I think.

Yes

>> unlocked_stdio.3: Join fread_unlocked(3)? Or not?
>
> I think not.>
> But I did *add* a few blank lines here.

Okay

>
>> xdr.3: wsfix: g/) (/s//)(/
>> (See if there are any other pages with this
>> that I may haven't seen.)
>
> Done.
>
> Plus: error.3, ftw.3, glob.3, pthread_create.3, rpc.3

A few more:
signal.3 (NOTES)
malloc_hook.3 (EXAMPLES)

>> rtnetlink.7: 78-col
>
> 78-col looks okay already?

Yes

>
>> sigevent.7: s/) (/)(/
>
> Done.
>
>> If you move the comments a few chars to the right (3<=x<=6),
>> you will compact one line
>
> I prefer to leave as is.

Okay

>
>> Also, curiously execveat(2), which is the one that started all this,
>> didn't look bad :p
>
> True.
>
>> So we'll have to grep for .nf/.fi too after this.
>
> Well, I just fixed most of them. The following perhaps need further
> consideration:
>
> man1/iconv.1
> man1/localedef.1
> man1/time.1
> man2/select_tut.2
> man3/string.3
> man4/sk98lin.4
> man4/smartpqi.4
> man7/man.7
> man7/man-pages.7
> man8/iconvconfig.8
> man8/ldconfig.8
> man8/ld.so.8
> man8/zdump.8
> man8/zic.8
>
> The last two are imported pages, so should probably be ignored.
> Perhaps none of the remainder really matter.
>
>> Things to note for other patches:
>>
>> isw*.3: Rewrite into one page similar to isalpha.3?
>> Does it really need so many pages?
>
> There sure is a lot of repetition across those pages...

I'll add it to my TODO list.

>
>> recno.3: Review: no APIs
>
> It's a strange page, but I'm not sure that anything needs fixing.
>
>> string.3: What is the criterion for functions to be there?
>> Also, there are functions which are already documented
>> in their own pages (see strcpy(3))
>> Some others don't appear there (see memcpy(3)
>> eventhough they are in string.h.
>
> See also bstring(3)
>
> bstring(3) and string(3) are ancient pages. I'm not entirely
> convinced of their value. I suppose thay are useful in the sense
> that you get a list of related functions. It is of course
> anomalous that string(3) and brief function descriptions
> while bstring(3) does not.
>
> Cheers,
>
> Michael
>
>

Cheers,

Alex

--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/