Re: Make --help output fit within 80 columns per line

From: torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>, htamfids(at)gmail(dot)com
Cc: Masahiro Ikeda <ikedamsh(at)oss(dot)nttdata(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Make --help output fit within 80 columns per line
Date: 2023-09-25 06:27:12
Message-ID: eba6645a0e228958d8541f213d66da0f@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 19, 2023 at 3:23 AM Greg Sabino Mullane <htamfids(at)gmail(dot)com>
wrote:
Thanks for your investigation!

> On Fri, Sep 15, 2023 at 11:11 AM torikoshia
> <torikoshia(at)oss(dot)nttdata(dot)com> wrote:
>> I do not intend to adhere to this rule(my terminals are usually bigger
>> than 80 chars per line), but wouldn't it be a not bad direction to use
>> 80 characters for all commands?
>
> Well, that's the question du jour, isn't it? The 80 character limit is
> based on punch cards, and really has no place in modern systems. While
> gnu systems are stuck in the past, many other ones have moved on to
> more sensible defaults:
>
> $ wget --help | wc -L
> 110
>
> $ gcloud --help | wc -L
> 122
>
> $ yum --help | wc -L
> 122
>
> git is an interesting one, as they force things through a pager for
> their help, but if you look at their raw help text files, they have
> plenty of times they go past 80 when needed:
>
> $ wc -L git/Documentation/git-*.txt | sort -g | tail -20
> 109 git-filter-branch.txt
> 109 git-rebase.txt
> 116 git-diff-index.txt
> 116 git-http-fetch.txt
> 117 git-restore.txt
> 122 git-checkout.txt
> 122 git-ls-tree.txt
> 129 git-init-db.txt
> 131 git-push.txt
> 132 git-update-ref.txt
> 142 git-maintenance.txt
> 144 git-interpret-trailers.txt
> 146 git-cat-file.txt
> 148 git-repack.txt
> 161 git-config.txt
> 162 git-notes.txt
> 205 git-stash.txt
> 251 git-submodule.txt
>
> So in summary, I think 80 is a decent soft limit, but let's not stress
> out about some lines going over that, and make a hard limit of perhaps
> 120.

+1. It may be a good compromise.
For enforcing the hard limit, is it better to add a regression test like
patch 0001?

On 2023-09-21 16:45, Peter Eisentraut wrote:
> On 31.08.23 09:47, torikoshia wrote:
>> BTW, psql --help outputs the content of PGHOST, which caused a failure
>> in the test:
>>
>> ```
>> -h, --host=HOSTNAME      database server host or socket directory
>>                          (default:
>> "/var/folders/m7/9snkd5b54cx_b4lxkl9ljlcc0000gn/T/LobrmSUf7t")
>> ```
>>
>> It may be overkill, added a logic for removing the content of PGHOST.
>
> I wonder, should we remove this? We display the
> environment-variable-based defaults in psql --help, but not for any
> other programs. This is potentially misleading.

Agreed. It seems inconsistent with other commands.
Patch 0002 removed environment-variable-based defaults in psql --help.

--
Regards,

--
Atsushi Torikoshi
NTT DATA Group Corporation

Attachment Content-Type Size
v1-0001-Added-a-test-for-checking-the-line-length-of-help.patch text/x-diff 992 bytes
v1-0002-Squashed-commit-of-the-following.patch text/x-diff 2.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yugo NAGATA 2023-09-25 06:32:04 Doc: vcregress .bat commands list lacks "taptest"
Previous Message Kuwamura Masaki 2023-09-25 06:22:38 Clarify where the severity level is defined