Re: Make --help output fit within 80 columns per line - Mailing list pgsql-hackers
| From | torikoshia |
|---|---|
| Subject | Re: Make --help output fit within 80 columns per line |
| Date | |
| Msg-id | 7ab6295d479544ae9acb926dc3e556cf@oss.nttdata.com Whole thread Raw |
| In response to | Re: Make --help output fit within 80 columns per line (Masahiro Ikeda <ikedamsh@oss.nttdata.com>) |
| Responses |
Re: Make --help output fit within 80 columns per line
Re: Make --help output fit within 80 columns per line |
| List | pgsql-hackers |
On Mon, Aug 21, 2023 at 1:09 PM Masahiro Ikeda
<ikedamsh@oss.nttdata.com> wrote:
> (1)
> Why don't you add test for the purpose? It could be overkill...
> I though the following function is the best place.
Added the test.
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.
On 2023-08-23 09:45, Masahiro Ikeda wrote:
> Hi,
>
> On 2023-08-22 22:57, torikoshia wrote:
>> On 2023-08-21 13:08, Masahiro Ikeda wrote:
>>> (2)
>>>
>>> Is there any reason that only src/bin commands are targeted? I found
>>> that
>>> we also need to fix vacuumlo with the above test. I think it's better
>>> to
>>> fix it because it's a contrib module.
>>>
>>> $ vacuumlo --help | while IFS='' read line; do echo $((`echo $line |
>>> wc -m` - 1)) $line; done | sort -n -r | head -n 2
>>> 84 -n, --dry-run don't remove large objects, just show
>>> what would be done
>>> 74 -l, --limit=LIMIT commit after removing each LIMIT large
>>> objects
>>
>> This is because I wasn't sure making all --help outputs fit into 80
>> columns per line is right thing to do as described below:
>>
>> | If this is the way to go, I'll do same things for contrib commands.
>>
>> If there are no objection, I'm going to make other commands fit within
>> 80 columns per line including (4).
>
> OK. Sorry, I missed the sentence above.
> I'd like to hear what others comment too.
Although there are no comments, attached patch modifies vaccumlo.
>>> (3)
>>>
>>> Is to delete '/mnt/server' intended? I though it better to leave it
>>> as
>>> is since archive_cleanup_command example uses the absolute path.
>>>
>>> - " pg_archivecleanup /mnt/server/archiverdir
>>> 000000010000000000000010.00000020.backup\n"));
>>> + " pg_archivecleanup archiverdir
>>> 000000010000000000000010.00000020.backup\n"));
>>>
>>> I will confirmed that the --help text are not changed and only
>>> the line breaks are changed. But, currently the above change
>>> break it.
>>
>> Yes, it is intended as described in the thread.
>>
>> https://www.postgresql.org/message-id/20230615.152036.1556630042388070221.horikyota.ntt%40gmail.com
>>
>> | We could shorten it by removing the "/mnt/server" portion, but
>> I'm not sure if it's worth doing.
>>
>> However, I feel it is acceptable to make an exception and exceed 80
>> characters for this line.
>
> Thanks for sharing the thread. I understood.
>
> It seems that the directory name should be consistent with the example
> of archive_cleanup_command. However, it does not seem appropriate to
> make archive_cleanup_command to use a relative path.
>
> ```
>> pg_archivecleanup --help
> (snip)
> e.g.
> archive_cleanup_command = 'pg_archivecleanup /mnt/server/archiverdir
> %r'
>
> Or for use as a standalone archive cleaner:
> e.g.
> pg_archivecleanup /mnt/server/archiverdir
> 000000010000000000000010.00000020.backup
> ```
>
> IMHO, is simply breaking the line acceptable?
Agreed.
> (4)
> I found that some binaries, for example ecpg, are not tested with
> program_help_ok(). Is it better to add tests in the patch?
Added program_help_ok() to ecpg and pgbench.
Although pg_regress and zic are not tested using program_help_ok, but
left as they are because they are not commands that users execute
directly.
--
Regards,
--
Atsushi Torikoshi
NTT DATA Group Corporation
Attachment
pgsql-hackers by date: