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

On 2023-09-12 15:27, Peter Eisentraut wrote:
> Also, it would be very useful if the TAP test function could print out
> the violating lines if a test fails. (Similar to how is() and like()
> print the failing values.)

Attached patch for this.
Below are the the outputs when test failed:

```
$ cd contrib/vacuumlo
$ make check
...(snip)...
t/001_basic.pl .. 1/?
# Failed test ' -n, --dry-run don't remove large
objects, just show what would be done'
# at
/home/atorik/postgres/contrib/vacuumlo/../../src/test/perl/PostgreSQL/Test/Utils.pm
line 850.
# Looks like you failed 1 test of 21.

# Failed test 'vacuumlo --help outputs fit within 80 columns per line'
# at t/001_basic.pl line 10.
# Looks like you failed 1 test of 9.
t/001_basic.pl .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/9 subtests

Test Summary Report
-------------------
t/001_basic.pl (Wstat: 256 (exited 1) Tests: 9 Failed: 1)
Failed test: 4
Non-zero exit status: 1
Files=1, Tests=9, 0 wallclock secs ( 0.01 usr 0.01 sys + 0.04 cusr
0.01 csys = 0.07 CPU)
Result: FAIL
```

```
$ cat tmp_check/log/regress_log_001_basic
# Running: vacuumlo --help
[23:11:10.378](0.230s) ok 1 - vacuumlo --help exit code 0
[23:11:10.379](0.001s) ok 2 - vacuumlo --help goes to stdout
[23:11:10.379](0.000s) ok 3 - vacuumlo --help nothing to stderr
[23:11:10.380](0.000s) # Subtest: vacuumlo --help outputs fit within 80
columns per line
[23:11:10.380](0.001s) ok 1 - vacuumlo removes unreferenced large
objects from databases.
[23:11:10.380](0.000s) ok 2 -
[23:11:10.381](0.000s) ok 3 - Usage:
[23:11:10.381](0.000s) ok 4 - vacuumlo [OPTION]... DBNAME...
[23:11:10.381](0.000s) ok 5 -
[23:11:10.381](0.000s) ok 6 - Options:
[23:11:10.381](0.000s) ok 7 - -l, --limit=LIMIT commit
after removing each LIMIT large objects
[23:11:10.382](0.000s) ok 20 - Report bugs to
<pgsql-bugs(at)lists(dot)postgresql(dot)org>.
[23:11:10.382](0.000s) ok 21 - PostgreSQL home page:
<https://www.postgresql.org/>
[23:11:10.382](0.000s) 1..21
[23:11:10.382](0.000s) # Looks like you failed 1 test of 21.
[23:11:10.382](0.000s) not ok 4 - vacuumlo --help outputs fit within 80
columns per line
[23:11:10.382](0.000s)
[23:11:10.382](0.000s) # Failed test 'vacuumlo --help outputs fit
within 80 columns per line'
# at t/001_basic.pl line 10.
# Running: vacuumlo --version
[23:11:10.388](0.005s) ok 5 - vacuumlo --version exit code 0
[23:11:10.388](0.000s) ok 6 - vacuumlo --version goes to stdout
[23:11:10.388](0.000s) ok 7 - vacuumlo --version nothing to stderr
# Running: vacuumlo --not-a-valid-option
[23:11:10.391](0.003s) ok 8 - vacuumlo with invalid option nonzero exit
code
[23:11:10.391](0.000s) ok 9 - vacuumlo with invalid option prints error
message
[23:11:10.391](0.000s) 1..9
[23:11:10.391](0.000s) # Looks like you failed 1 test of 9.
```

I feel using subtest in Test::More improves readability.

On 2023-09-14 02:46, Greg Sabino Mullane wrote:
> All this seems an awful lot of work to support this mythical 80-column
> terminal user.
> It's 2023, perhaps it's time to widen the default assumption past 80
> characters?

That may be a good idea.

However, from what I have seen some basic commands like `ls` in my Linux
environments, the man command has over 100 characters per line, while
the output of the --help option seems to be within 80 characters per
line.
Also, the current PostgreSQL commands follow the "no more than 80
characters per line".

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?

Thoughts?

--
Regards,

--
Atsushi Torikoshi
NTT DATA Group Corporation