-
-
Notifications
You must be signed in to change notification settings - Fork 11.3k
[RFC] Improve handling of --verbose/-v argument #46387
Comments
Agreed this makes sense to make more consistent 👍 |
I think it’s fine to keep it for the convention. A lot of programs print their version with both |
My subjective impression was that there are more programs that interpret But in this case, I still firmly believe that clarity ( |
Unfortunately both are trumped by "there will be a lot of scripts in the wild that expect this behaviour". The rest of the proposed changes I agree with though 👍 |
I was under the impression than
One could argue that in
Yep. |
Scripts written against undocumented flags deserve to be broken. We shouldn't deliberately break things, but we also shouldn't shy away from it because it could inconvenience a few people, if it improves the situation. There's no progress without change and with change comes occasional breakage. Ultimately, the decision is of course with the people who will most likely have to deal with the consequences, i.e. long-term contributors/maintainers. Just wanted to disclose my thought process. |
That would be a reasonable thing to expect, but that's not how things stand currently. By that measure, at least |
Sure. We've told people for years the command-line is our API so we try to be fairly careful about breaking it. I believe another original motivation for this was that Ruby treats the |
I think we should at least fix the |
Thanks for pointing that out! I don't necessarily think this is good, but it pretty much explains the current behavior with all its quirks. In that case I retreat and accept this design decision, unless other maintainers have strong opinions one way or the other.
Even this is perfectly consistent with Ruby's interpretation of that switch, if I understand it correctly. It didn't feel right to me, but I also wasn't aware of where that came from. To quote from Ruby's manual:
|
Agreed. It should be assumed to be verbose unless the actual argument. |
So, that's the behaviour we're emulating. I do think the "will print its version at the beginning" can be killed but the "no other switches" should remain the same. |
Addendum: The only thing inconsistent about the current implementation is that something like |
To summarize, the current proposal (supported at least by Mike) would be:
Did I get that right? And do we continue to generate slightly different output for |
I think we can unify their output. That seems like a mistake rather than intentional. Otherwise 👍 |
To which one? I'm leaning towards the Ruby precedent of always prefixing the project name. |
Yeh, prefixing project name works for me 👍 |
Cool. 😎 Let's give other maintainers (or even interested users) some time to voice their opinion on this matter and later on I'll prepare a PR. |
👍 on this. |
👍 from me too. |
Please see PR #46790 for the code resulting from this discussion. |
Currently, the handling of the
--verbose
argument and its short version-v
is pretty inconsistent and gives a horrible user experience. Compare these outputs (thelist
command is just an example):Short Form
-v
Notice how the header
Homebrew 0.9.5 (git revision 5979e; last commit 2015-11-24)
is either printed or not depending on the position of the-v
option. In both cases, it is interpreted to mean “verbose”.Long Form
--verbose
Suddenly,
--verbose
is recognized as a command and thus not accepted in the same place where its short counterpart is (so it isn't exactly equivalent).Other Related Cases
Without any other arguments
-v
is just an odd variation of--version
withHomebrew
prefixed.Suggestion
Passing
-v
as the first argument is undocumented, as is its special handling and the additional header it prints. Passing-v
as the sole argument doesn't seem very useful given that--version
also exists (and is documented). If I'm not the only one who feels that way, I volunteer to clean upbrew.rb
accordingly.The text was updated successfully, but these errors were encountered: