On 2023-09-25 15:27, torikoshia wrote:
On Tue, Sep 19, 2023 at 3:23 AM Greg Sabino Mullane
<htamf...@gmail.com> wrote:
Thanks for your investigation!
On Fri, Sep 15, 2023 at 11:11 AM torikoshia
<torikos...@oss.nttdata.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?
Ugh, regression tests failed and it appears to be due to reasons related
to meson.
I'm going to investigate it.
--
Regards,
--
Atsushi Torikoshi
NTT DATA Group Corporation
