Re: [PATCH] execveat.2: srcfix

["Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>]

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/
http://www.alejandro-colomar.es/