cobra
cobra copied to clipboard
fix: generate docs for commands containing slashes
Previously, a command such as:
&cobra.Command{Use: "run/first [OPTIONS] arg1 arg2"}
would fail generation with an error "no such file or directory" because the generating code would expect some directory ending in run
.
This PR moves from using strings.Replace
to strings.Replacer
which supports mapping multiple replacements in a single invocation. Most of the code can use the utility function cleanCommandName
. However, manpages use -
rather than _
for the seperator so the replacer is defined inline.
I also found that the private genMan function doesn't support passing the custom separator defined in GenManTreeOptions, which is possibly another bug as the SEE ALSO output would be inconsistent whenever the user defines a custom separator. I didn't resolve this issue in this PR because I'm unfamiliar with the manpage format.
Please review the outputs in my example repo: https://github.com/jimschubert/cobraslash_example
fixes #1616
See https://github.com/spf13/cobra/pull/1530.
If #1530 gets merged first, I have no problem fixing the merge conflicts in this PR. But my PR is solving a different issue.
Thanks fro this! #1530 has merged - can you rebase and get those changes and we can look at this? Thanks much!!
@jpmcb thanks. I've just rebased and retested. It's good to go.
The Cobra project currently lacks enough contributors to adequately respond to all PRs. This bot triages issues and PRs according to the following rules:
- After 60d of inactivity, lifecycle/stale is applied. - After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied and the PR is closed. You can:
- Make a comment to remove the stale label and show your support. The 60 days reset. - If a PR has lifecycle/rotten and is closed, comment and ask maintainers if they'd be interseted in reopening.
Not stale, just waiting on merge.
I've just noticed new file conflicts since I commented three weeks ago. I'll try to fix those conflicts this weekend.
Sounds good @jimschubert - so sorry for the delay on this!
it's no problem. I know how it can be :)
The conflicts were actually just a couple of copyright headers. It's all cleaned up now.