This PR makes it possible to get a more specific help about just one CMD. Example:
$ bitcoind --help=server
Bitcoin Core version v0.19.99.0-6fdf7dda6
Usage: bitcoind [options] Start Bitcoin Core
-server
Accept command line and JSON-RPC commands
If no arg was given or the arg doesn't exist, it will return the normal full help.
~0
Not worth the change, additional code. grep -C 3 works decently as-is.
#17841 (comment) by @jonatack:
unneeded and non-issue, grepping with -A/B/C flags works well.
I'm not aware of any Unix tool with this kind of syntax.
Is there any precedent for the --help=command syntax in any widely used Unix tool?
Generally I think we should try to follow well established Unix command-line conventions as much as possible.
Surprises might be fun in other parts of life, but not when it comes to user interfaces :)
Is there any precedent for the --help=command syntax in any widely used Unix tool?
Not in Unix but in Bitcoin Core! The RPC help command works similar
=0 on this
Conceptually I think the idea itself is clever. Currently it simply prints the short description (which is the same as using grep) but there could be a short as well as a more verbose help, only printed on request, for settings.
I'm not opposed to innovation in command line interfaces (because it's not "UNIX convention"), on the other hand, I'm not sure this is something people will actually use (because indeed, no one expects it) and warrants the extra complexity. I'm also not sure bitcoin core is the place for this kind of innovation and discussion around it.
521 | + return this->GetHelpMessage(); 522 | + 523 | + std::pair<std::string, ArgsManager::Arg> command; 524 | + bool cmdExists = false; 525 | + LOCK(cs_args); 526 | + for (const auto& arg_map : m_available_args) {
Please factor this out to a function to get info for a specified setting name instead of having this loop in-line.
What's the point of porting this to a function. It is only used once.
It helps encapsulate logic by naming a block of code. I don't have strong opinions on this but I think it would be helpful for readers. It looks like this loop is determining if the provided helpName is a valid command name. By naming this block of code it becomes significantly easier to reason about IMO.
530 | + cmdExists = true; 531 | + break; 532 | + } 533 | + } 534 | + } 535 | + // Return the full help if the command is not existent
It should be an error IMO if the command is not existent. The "in case of doubt dump the manual in the users face" behavior frequently frustrates me in other software :laughing:
Error with bitcoin-qt have been fixed
482 | + std::string helpArg = gArgs.GetArg("-help", ""); 483 | + bool specialHelp = false; 484 | + if (helpArg == "") 485 | + specialHelp = false; 486 | + else 487 | + specialHelp = true;
can/should this be simplified to bool specialHelp = helpArg != "";?
23 | @@ -24,7 +24,7 @@ class HelpMessageDialog : public QDialog 24 | Q_OBJECT 25 | 26 | public: 27 | - explicit HelpMessageDialog(interfaces::Node& node, QWidget *parent, bool about); 28 | + explicit HelpMessageDialog(interfaces::Node& node, QWidget *parent, bool about, bool specHelp = false);
nit: spec might also be read as specific or specification when a new reader comes into the codebase. I think naming it with the full specialHelp you use in https://github.com/bitcoin/bitcoin/pull/17901/files#diff-8c9d79ba40bf702f01685008550ac100R482 would make it easier on new readers to understand what's going on.
525 | + LOCK(cs_args); 526 | + for (const auto& arg_map : m_available_args) { 527 | + for (auto const& arg : arg_map.second) { 528 | + if (arg.first == "-" + helpName) { 529 | + command = arg; 530 | + cmdExists = true;
do you need cmdExists? Can we check if command was set (in the if statement below) without leaning on this extra variable?
I also though about this but I'm not sure about how to do it with such a type
I agree with @practicalswift that we should stay close to unix style as much as possible. I've seen interfaces of the form cmd help sumbcommand and cmd subcommand --help. I'm not sure if those are unix philosophies but I think there's precedent there.
@laanwj what do you perceive as the risk of this extra complexity? I'm still new to the community and am trying to understand how risk/reward tradeoffs are thought about. I understand that this PR adds more complexity but I don't see the complexity as high risk.
The RPC help command works similar
Not quite similar, calling just help RPC list all commands, not the whole RPC help.
Concept NACK, sorry, I believe the user is better served with | less or | grep.
Concept ~0. I agree that Bitcoin Core isn't really the place where we need to be "innovating" or doing anything unexpected in regards to command line usage and/or features. As mentioned here and in #17841, there are plenty of ways for a user to extract the help information they'd like without adding additional complexity to the codebase.
Will close this, lost motivation on it
