| 142
|
|
|
Frank Mueller |
12 years ago
|
 |
|
| 141
|
|
|
William Reade |
12 years ago
|
|
|
| 140
|
|
|
William Reade |
12 years ago
|
|
|
| 139
|
|
|
Roger Peppe |
12 years ago
|
|
|
| 138
|
|
|
Roger Peppe |
12 years ago
|
|
|
| 137
|
|
|
Frank Mueller |
12 years ago
|
|
|
| 136
|
|
|
William Reade |
12 years ago
|
|
|
| 135
|
|
|
Frank Mueller |
12 years ago
|
|
|
| 134
|
|
Moved printUsage to Info
It became apparent that printUsage wasn't really using a Command, it was
just using its Info so heavily as to imply it wanted to be a method on Info;
and, having moved printUsage to Info, it became clear that options are the
sole preserve of the gnuflag.FlagSet, and should not be mentioned in
Info.Args (because to do so is to assert knowledge about the state of a
shared resource, the FlagSet, without legitimately being able to do so). So,
printUsage is now also responsible for inserting `[options]` into the usage
line, in exactly the same way as it does the section actually describing
those options (ie: it only does so if they exist).
As a side-effect, SuperCommand `[options]` are placed before `<command> ...`
in the usage line for the bare SuperCommand; this is IMO sensible because
we're displaying the options that apply whatever command you select, and
which actually *do* work in that position; ofc, when displaying help for a
particular subcommand, we put the options after the command (and before its
positional arguments). So we get:
usage: juju [options] <command> ...
...and:
usage: juju bootstrap [options]
...each of which accurately captures the possibilities in the appropriate
situation.
This branch also includes slightly heavier testing for SuperCommand's Info,
and small tweaks to ensure consistent output of SuperCommand documentation
as expected by those tests.
R=rog, niemeyer
CC=
https://codereview.appspot.com/6123049
|
William Reade |
12 years ago
|
|
|
| 133
|
|
|
Roger Peppe |
12 years ago
|
|
|
| 132
|
|
|
Roger Peppe |
12 years ago
|
|
|
| 131
|
|
|
Frank Mueller |
12 years ago
|
|
|
| 130
|
|
|
Roger Peppe |
12 years ago
|
|
|
| 129
|
|
|
William Reade |
12 years ago
|
|
|
| 128
|
|
|
William Reade |
12 years ago
|
|
|
| 127
|
|
|
Roger Peppe |
12 years ago
|
|
|
| 126
|
|
|
Roger Peppe |
12 years ago
|
|
|
| 125
|
|
Add cmd.Context type to enable output capture and environment control
In order to run a Command inside another process, the host process needs to
know the client's working directory (for relative file paths), and it needs
separate output streams (so that it goes where it's intended).
The only impact on existing Commands is that their Run method now expects a
*cmd.Context; the only command that's materially affected is SuperCommand,
which becomes slightly simpler (because logging setup is now the
responsibility of the Context; SuperCommand just parses the args and hands
them over).
FlagSets are now always constructed with ContinueOnError, and with
configurable output; this unifies error handling and usage printing (there's
now only one code path for each), and allows us to correctly print usage for
commands that don't have any sensible options (eg open-port). As a
side-effect, it's much simpler to test command-line parsing for arbitrary
commands, because errors no longer cause os.Exit to be called. For clarity's
sake, pre-existing tests have been left untouched; expect a followup branch
that tidies up main and main_test in juju and jujud.
PrintUsage and NewFlagSet are now private (in addition to expecting an
io.Writer for output), because they weren't used externally in the first
place, and in practice were just dirtying up the interface.
R=niemeyer, rog
CC=
https://codereview.appspot.com/5758050
|
William Reade |
12 years ago
|
|
|
| 124
|
|
|
Roger Peppe |
12 years ago
|
|
|
| 123
|
|
|
Frank Mueller |
12 years ago
|
|
|
collapse all