I hope I'm not out of line responding personally, but since the bug report is 
closed I'm not sure if anyone will ever see this.

7 Jul 2026, 14:38 by [email protected]:

> Depends on whether you want fast development (where Python excels) or fast 
> performance (where GNU grep runs rings around Python). Your choice, of course.
>
My criterion is much simpler: can I do the job with reasonable effort. Every 
language I've learnt in the past 20 years has been task-specific, and a huge 
barrier to getting involved in a project.

> It wasn't a waste at all. It's helpful to get fresh eyes to look at the 
> documentation, and your comments exposed a real deficiency. Thank you.
>
I know that if I had any good ideas, billions of people would have thought of 
them already. I can't help with the software, so I hoped to help with 
documentation, that largely seems written for the maintainers and not the rest 
of us.

> The consensus seems to be that the grep man page should defer to regexp(7), 
> and this seems good to me as well: it lessens the burden on the reader (why 
> should there be duplicate documentation for regexps in the manual?) and on 
> maintenance.
>
Even if the man page only said 'grep uses POSIX regex character classes' I 
could figure out the rest. I just don't know how I can be expected to see 
[:print:], [:punct:] and [:graph:] and (a) recognise them as POSIX character 
classes (I never knew that was a thing), or (b) know exactly what they capture. 
I tried to figure it out myself.

I agree that a lot of man pages are long and irrelevant. I usually grep my way 
through them to find where I hope the answer will be. Perhaps it would help if 
they had that use case in mind? If it wasn't so political, I'd suggest changes 
to other man pages, too. I'm just trying to avoid more "How dare you" responses.
> So I installed the attached patches to try to do this. The first changes 
> grep's man page to defer to regexp(7) and to document only the places where 
> GNU grep differs from standard POSIX. The second changes the documentation to 
> fix some glitches I noticed when updating the man page (this is part of that 
> maintenance duplication of effort, alas).
>
Ironically, tr's man page is very similar to what I proposed. I still think it 
should have objective references instead of "white space" or "punctuation". tr 
doesn't appear to have collapsed with this weight. Nevertheless, perhaps 
someone with standing can propose linking tr's man page link to regexp's.

Thank you for considering my feedback. I'm happy to revise if I can be useful.



Reply via email to