From: Oskari Pirhonen <xxc3ncoredxx@gmail.com>
To: Alejandro Colomar <alx.manpages@gmail.com>
Cc: Sam James <sam@gentoo.org>,
linux-man@vger.kernel.org, Tom Schwindl <schwindl@posteo.de>,
Guillem Jover <guillem@hadrons.org>,
Brian Inglis <Brian.Inglis@Shaw.ca>,
Matt Jolly <Matt.Jolly@footclan.ninja>
Subject: Re: [PATCH v2] stdc: some improvements
Date: Sat, 25 Mar 2023 00:08:32 -0500 [thread overview]
Message-ID: <ZB6B0KJgvwexgRnR@dj3ntoo> (raw)
In-Reply-To: <a16c019b-66dd-adc1-769c-8a6fb813e288@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4635 bytes --]
Hi,
On Fri, Mar 24, 2023 at 13:21:58 +0100, Alejandro Colomar wrote:
> Hi Oskari, Sam,
>
> On 3/24/23 06:07, Oskari Pirhonen wrote:
> > - Some small stylistic changes such as removing trailing semicolons and
> > noisy `shift` calls.
>
> But they are sooo pretty =) That's a little OCD of mine putting
> semicolons in shell scripts. Maybe I read too much C, but it feels
> good to see punctuation marks at the end of sentences. I prefer to
> keep semicolons.
>
Style is obviously your call here.
> > - Ensure pcregrep exists. It is installed as pcre2grep on my machine, so
> > check for both and error out if neither is found. Prefer pcre2grep
> > (installed by libpcre2) because libpcre is EOL.
>
> Hmm, I didn't know about pcre2grep(1). I've applied the following:
>
... snip ...
>
> libc_summ_c89()
>
> > - Make libc_summ() standard-agnostics by passing in the filter
> > expression and the path to the doc as arguments.
>
> It's really standards agnostic except for C89. ISO C drafts
> are pretty much all the same except for the original one, since
> I was really ANSI C. That's why C99 and C11 (and C2x if we add
> it) can reuse libc_summ(), but C89 is an exception.
>
That's good to know.
> > - Make libc_summ() error out if the doc is not found.
>
> The shell already errors out with a quite readable message:
>
> $ ./bin/stdc c99 fgets
> ./bin/stdc: line 54: /usr/local/share/doc/c/c99/n1256.foo: No such file or directory
> $ echo $?
> 1
>
> Is it not good enough?
>
I suppose that is fine for me. I may be too used to having to performing
my own checks for files that I ignored Bash being able to do the same.
> > - Give basic usage information on usage errors.
>
> I prefer writing a man page. It keeps the source code simpler.
> Please keep this suggestion around, and resend it if you feel it's
> necessary after having a man page (1 or 2 weeks maybe).
>
Heh. Perhaps you're biased towards man pages ;)
I'll keep it around (rebasing as needed for current and possibly future
edits).
> > - Make the standard version match case insensitive.
>
> Okay.
>
> >
> > Signed-off-by: Oskari Pirhonen <xxc3ncoredxx@gmail.com>
>
> Please send individual patches for each of the logical changes.
>
Whoops. Will do in the future.
> > ---
> > v1 -> v2:
> > - Prefer pcre2grep from libpcre2. Suggested by Sam on IRC.
> >
> > bin/stdc | 101 +++++++++++++++++++++++++++++++++++++------------------
> > 1 file changed, 68 insertions(+), 33 deletions(-)
> >
> > diff --git a/bin/stdc b/bin/stdc
> > index 8c725a2..0d322af 100755
> > --- a/bin/stdc
> > +++ b/bin/stdc
> > @@ -1,65 +1,100 @@
> > -#!/bin/bash
> > +#!/usr/bin/env bash
> >
> > -set -Eefuo pipefail;
> > +set -Efuo pipefail
>
> Why not set -e? It's not documented in the commit message.
>
I forgot to mention that in the message, but it's no longer relevant
since you switched it to just pcre2grep. With `set -e` it was aborting
the script when `type -P` failed.
... snip ...
> >
> > -case "$1" in
> > +case "${1@L}" in
>
> I'm not a fan of shell features. I prefer some command like
> "$(printf "%s" "$1" | tr [[:upper:]] [[:lower:]])"
> which is much more readable (IMO). Does that look good to you?
>
Fine by me.
> > c89)
> > - shift;
> > - libc_summ_c89 \
> > - | grep_proto $@;
> > + libc_summ "$c89_filter" "$c89_doc" \
> > + | grep_proto "$2"
... snip ...
> > +esac
> > +
> > +# vim: set noexpandtab:
>
> I'm not sure we want vim comments like this one for every file. Aren't
> they too noisy? But maybe it's just me. I use things like the following
> for when I contribute regularly to projects that use a different rule for
> indentation:
>
> au bufnewfile,bufread ~/src/linux/man-pages/*/man*/* setlocal expandtab
> au bufnewfile,bufread ~/src/linux/man-pages/*/man*/* setlocal shiftwidth=4
> au bufnewfile,bufread ~/src/linux/man-pages/*/man*/* setlocal softtabstop=4
> au bufnewfile,bufread ~/src/linux/man-pages/*/man*/* setlocal tabstop=5
>
> au bufnewfile,bufread ~/src/nginx/* setlocal expandtab
> au bufnewfile,bufread ~/src/nginx/* setlocal shiftwidth=4
> au bufnewfile,bufread ~/src/nginx/* setlocal softtabstop=4
> au bufnewfile,bufread ~/src/nginx/* setlocal tabstop=5
>
> (tabstop=5 is for realizing when something is actually a tab, which for
> example happens in Makefiles in NGINX.)
>
This is an interesting idea that I've never considered before.
Thanks for at least accepting some of the suggestions.
- Oskari
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
prev parent reply other threads:[~2023-03-25 5:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-24 5:07 [PATCH v2] stdc: some improvements Oskari Pirhonen
2023-03-24 12:21 ` Alejandro Colomar
2023-03-24 12:46 ` Tom Schwindl
2023-03-25 5:08 ` Oskari Pirhonen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZB6B0KJgvwexgRnR@dj3ntoo \
--to=xxc3ncoredxx@gmail.com \
--cc=Brian.Inglis@Shaw.ca \
--cc=Matt.Jolly@footclan.ninja \
--cc=alx.manpages@gmail.com \
--cc=guillem@hadrons.org \
--cc=linux-man@vger.kernel.org \
--cc=sam@gentoo.org \
--cc=schwindl@posteo.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox