Thread (6 messages) flat view 6 messages, 4 authors, 2022-02-12

Re: Custom subcommand help handlers

From: Philip Oakley <hidden>
Date: 2021-12-23 15:07:51

On 22/12/2021 19:53, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
On Mon, 20 Dec 2021, Junio C Hamano wrote:
quoted
"brian m. carlson" [off-list ref] writes:
quoted
I should point out that in most cases on Unix, it _is_ expected that you
install your manual pages into the same place as everyone else, so in
this case, installing the HTML documentation alongside Git's may be the
best solution.
Yup, that sounds like the most sensible way to do things.
So what about `~/bin/git-my-reply-to-junio`? Do we expect people to write
a manual page and install it into `~/man/man1` and for `man` to pick that
up?
Yes, if they write one, and then tell man that you have extra
manpages there via MANPATH.

I expect people *not* to write a manual page in practice for such a
thing, though ;-)
In the very original use case reported in the git for windows issues
pages, I understood it that the provider of the git-foo script expected
that they would include some detection and response to the --help being
given as an option.

They had the issue that their windows users, using Git for Windows, do
not have the `man` package installed. Rather the `web` help of using the
.html version of the man page is used (needs administrator install in
some case). So user commands would need to provide both the man page for
Linux systems and some process to get the html equivalent into the right
folder - this latter case was the problem step. 

The expectation from the XY-Problem was that if the html (and possibly,
by implication, the man page) was not found by git, that the --help
option would be passed to the command itself for it the command to
process (or ignore)..

It is a bit of a rabbit hole.

Philip
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help