README.md in cliutils-1.2.8 vs README.md in cliutils-1.2.9
- old
+ new
@@ -120,11 +120,11 @@
* `messenger.error`: used to show a formatted-red error message.
* `messenger.info`: used to show a formatted-blue infomational message.
* `messenger.section`: used to show a formatted-purple sectional message.
* `messenger.success`: used to show a formatted-green success message.
-* `messenger.yellow`: used to show a formatted-yellow warning message.
+* `messenger.warn`: used to show a formatted-yellow warning message.
Let's see an example that uses them all:
```Ruby
messenger.section('STARTING ATTACK RUN...')
@@ -136,28 +136,41 @@
![alt text](https://raw.githubusercontent.com/bachya/cli-utils/master/res/readme-images/messenger-types-1.png "Basic Messenger Types")
`messenger` also includes two "block" methods that allow you to wrap program execution in messages that are "longer-term".
```Ruby
-messenger.info_block('Starting up...', 'Done!', multiline = false) { # do stuff here }
+# Outputs 'Starting up...', runs the code in
+# `# do stuff here`, and once complete,
+# outputs 'Done!' on the same line.
+messenger.info_block('Starting up...', 'Done!', multiline = false) {
+ # ...do stuff here...
+}
+
+# Outputs 'MY SECTION' and then runs
+# the code in `# do stuff here` before
+# proceeding.
+section_block('MY SECTION', multiline = true) {
+ # ...do stuff here...
+}
```
-`messenger` outputs 'Starting up...', runs the code in `# do stuff here`, and once complete, outputs 'Done!' on the same line. Note that `section_block` is the same exact signature (except for the method name, of course!).
-
### Message Wrapping
`PrettyIO` also gives `messenger` the ability to wrap your messages so that they don't span off into infinity. You can even control what the wrap limit (in characters) is:
```Ruby
+long_string = 'This is a really long message, okay? ' \
+'It should wrap at some point. Seriously. Wrapping is nice.'
+
CLIUtils::PrettyIO.wrap_char_limit = 50
-messenger.info('This is a really long message, okay? It should wrap at some point. Seriously. Wrapping is nice.')
+messenger.info(long_string)
puts ''
CLIUtils::PrettyIO.wrap_char_limit = 20
-messenger.info('This is a really long message, okay? It should wrap at some point. Seriously. Wrapping is nice.')
+messenger.info(long_string)
puts ''
CLIUtils::PrettyIO.wrap = false
-messenger.info('This is a really long message, okay? It should wrap at some point. Seriously. Wrapping is nice.')
+messenger.info(long_string)
```
![alt text](https://raw.githubusercontent.com/bachya/cli-utils/master/res/readme-images/wrapping.png "Text Wrapping")
### Prompting
@@ -206,11 +219,11 @@
W, [2014-03-29T15:14:34.844406 #4497] WARN -- : This warning should appear in STDOUT and file.txt
E, [2014-03-29T15:14:34.844553 #4497] ERROR -- : This error should appear in STDOUT and file.txt
D, [2014-03-29T15:14:34.844609 #4497] DEBUG -- : This debug message should only appear in file.txt
```
-Since you can attach Logger objects, each can have it's own format and severity level. Cool!
+Since you are attaching Logger objects, each can have it's own format and severity level. Cool!
## Configuration
CLIUtils offers a `Configurator` class and a `Configuration` module (which provides access to a shared instance of `Configurator`) that make managing a user's configuration parameters easy. Mix it in!
@@ -240,13 +253,13 @@
### Adding Data to Sections
There are two ways data can be managed in `configurator`: via its `@data` property or via some magic methods; your call:
```Ruby
-configuration.data[:user_data].merge!(username: 'bob')
+configuration.data[:user_data].merge!({ username: 'bob', age: 45 })
# OR
-configuration.user_data.merge!(username: 'bob')
+configuration.user_data.merge!({ username: 'bob', age: 45 })
```
### Saving to a File
When you're ready to save your configuration data to a YAML file:
@@ -260,10 +273,11 @@
```YAML
---
app_data:
user_data:
username: bob
+ age: 45
```
### Checking Configuration Versions
Often, you'll want to check the user's current version of your app against the last version that required some sort of configuration change. `configurator` allows for this via its `compare_version` method.
@@ -290,12 +304,11 @@
# stores the app's version in its configuration file.
# NOTE that you don't have to specify the section.
configuration.cur_version_key = :APP_VERSION
# Tell your configurator the name of the key that
-# stores the last version that needed a configuration
-# change.
+# stores the last version that needed a configuration change.
# NOTE that you don't have to specify the section.
configuration.last_version_key = :NEWEST_CONFIG_VERSION
# Run the check and use a block to get
# the current and "last-needing-changes"
@@ -314,11 +327,11 @@
Many times, CLI apps need to ask their users some questions, collect the feedback, validate it, and store it. CLIUtils makes this a breeze via the `Prefs` class.
### Basic Schema
-`Prefs` can load preferences information from either a YAML file (via a filepath) or from an array of preferences. In either case, the schema is the same; each prompt includes the following:
+`Prefs` can load preferences information from either a YAML file (via a filepath) or from an Array of preferences. In either case, the schema is the same; each prompt includes the following:
* `prompt` (**required**): the string to prompt your user with
* `default` (*optional*): an optional default to offer
* `config_key` (**required**): the Configurator key that this preference will use
* `config_section` (**required**): the Configurator section that this preference applies to
@@ -345,11 +358,11 @@
```Ruby
prefs = CLIUtils::Prefs.new('path/to/yaml/file')
```
-`Prefs` can also be instantiated via a Hash or an array of prompts; the overall schema remains the same:
+`Prefs` can also be instantiated via a Hash or an Array of prompts; the overall schema remains the same:
```Ruby
# Instantiation through a Hash
h = {
prompts: [
@@ -373,13 +386,13 @@
}
]
}
prefs = CLIUtils::Prefs.new(h)
-
+```
+```Ruby
# Instantiation through an Array
-
a = [
{
prompt: 'What is your name?',
default: 'Bob Cobb',
config_key: :name,
@@ -500,16 +513,19 @@
"But," you say, "I want to ensure that my user gives answers that conform to certain specifications!" Not a problem, dear user: `Prefs` gives you Validators. Currently supported Validators are:
```YAML
validators:
- - alphabetic # Must be made up of letters and spaces
- - alphanumeric # Must be made up of letters, numbers, and spaces
- - date # Must be a parsable date (e.g., 2014-04-03)
- - non_nil # Must be a non-nil value
- - numeric # Must be made up of numbers
- - url # Must be a fully-qualified URL
+ - alphabetic # Must be made up of letters and spaces
+ - alphanumeric # Must be made up of letters, numbers, and spaces
+ - date # Must be a parsable date (e.g., 2014-04-03)
+ - datetime # Must be a parsable datetime (e.g., 2014-04-03 9:34am)
+ - non_nil # Must be a non-nil value
+ - number # Must be made up of numbers
+ - filepath_exists # Must be a local filepath that exists (e.g., `/tmp/`)
+ - time # Must be a parsable time (e.g., 12:45pm or 21:08)
+ - url # Must be a fully-qualified URL
```
An example:
```YAML
@@ -521,11 +537,11 @@
- alphabetic
- prompt: How old are you?
config_key: age
config_section: personal_info
validators:
- - numeric
+ - number
```
```Ruby
prefs.ask
```
@@ -538,11 +554,11 @@
Finally, a common desire might be to modify the user's answer in some way before storing it. `Prefs` accomplishes this via Behaviors. Currently supported Behaviors are:
```YAML
validators:
- capitalize # Turns "answer" into "Answer"
- - local_filepath # Runs File.expand_path on the answer
+ - expand_filepath # Runs File.expand_path on the answer
- lowercase # Turns "AnSwEr" into "answer"
- prefix: 'test ' # Prepends 'test ' to the answer
- suffix: 'test ' # Appends 'test ' to the answer
- titlecase # Turns "the answer" into "The Answer"
- uppercase # Turns "answer" to "ANSWER"
@@ -566,10 +582,10 @@
```Ruby
prefs.ask
```
![alt text](https://raw.githubusercontent.com/bachya/cli-utils/master/res/readme-images/prefs-ask-behaviors.png "Behaviors")
-Note that behaviors are executed in order, which might give you different results than you're expecting. In the example above, for example, placing the `uppercase` behavior last in the list will uppercase *the entire string* (including prefix and suffix).
+Note that behaviors are executed in order, which might give you different results than you're expecting. Using the YAML above, for example, placing the `uppercase` behavior last in the list will uppercase *the entire string* (including prefix and suffix).
### Adding Pref Responses to a Configurator
Once the user has answered all the preference prompts, you can fold those answers back into a Configurator using the `ingest` method: