rbcli 0.2.0 → 0.2.1

data/docs/advanced/state_storage/index.html

@@ -582,6 +582,18 @@
   </li>
 
         
+          
+          
+          
+
+
+  <li class="md-nav__item">
+    <a href="../remote_execution/" title="Remote Execution" class="md-nav__link">
+      Remote Execution
+    </a>
+  </li>
+
+        
       </ul>
     </nav>
   </li>

data/docs/advanced/user_config_files/index.html

@@ -542,6 +542,18 @@
   </li>
 
         
+          
+          
+          
+
+
+  <li class="md-nav__item">
+    <a href="../remote_execution/" title="Remote Execution" class="md-nav__link">
+      Remote Execution
+    </a>
+  </li>
+
+        
       </ul>
     </nav>
   </li>

data/docs/development/code_of_conduct/index.html

@@ -495,6 +495,18 @@
   </li>
 
         
+          
+          
+          
+
+
+  <li class="md-nav__item">
+    <a href="../../advanced/remote_execution/" title="Remote Execution" class="md-nav__link">
+      Remote Execution
+    </a>
+  </li>
+
+        
       </ul>
     </nav>
   </li>

data/docs/development/contributing/index.html

@@ -495,6 +495,18 @@
   </li>
 
         
+          
+          
+          
+
+
+  <li class="md-nav__item">
+    <a href="../../advanced/remote_execution/" title="Remote Execution" class="md-nav__link">
+      Remote Execution
+    </a>
+  </li>
+
+        
       </ul>
     </nav>
   </li>
@@ -654,7 +666,7 @@
 <li>Update the version number in <code>version.rb</code></li>
 <li>Run <code>bundle exec rake install</code>, which will update <code>gemfile.lock</code> with the correct version and all dependency changes</li>
 <li>Run <code>docs-src/makesite.sh</code>, which re-compiles the documentation and pulls in the changelog and quick reference automatically</li>
-<li>Commit the above changes to master, but do not push</li>
+<li>Commit the above changes to master with a commit message of "vX.X.X" (where X.X.X is the version number), but do not push</li>
 <li>Run <code>bundle exec rake release</code>, which will create a git tag for the version, push git commits and tags, and push the <code>.gem</code> file to <a href="https://rubygems.org">rubygems.org</a>.</li>
 </ol>
                 
@@ -677,7 +689,7 @@
     <div class="md-footer-nav">
       <nav class="md-footer-nav__inner md-grid">
         
-          <a href="../../advanced/distributed_state_locking/" title="Distributed State Locking" class="md-flex md-footer-nav__link md-footer-nav__link--prev" rel="prev">
+          <a href="../../advanced/remote_execution/" title="Remote Execution" class="md-flex md-footer-nav__link md-footer-nav__link--prev" rel="prev">
             <div class="md-flex__cell md-flex__cell--shrink">
               <i class="md-icon md-icon--arrow-back md-footer-nav__button"></i>
             </div>
@@ -686,7 +698,7 @@
                 <span class="md-footer-nav__direction">
                   Previous
                 </span>
-                Distributed State Locking
+                Remote Execution
               </span>
             </div>
           </a>

data/docs/development/license/index.html

@@ -495,6 +495,18 @@
   </li>
 
         
+          
+          
+          
+
+
+  <li class="md-nav__item">
+    <a href="../../advanced/remote_execution/" title="Remote Execution" class="md-nav__link">
+      Remote Execution
+    </a>
+  </li>
+
+        
       </ul>
     </nav>
   </li>

data/docs/imported/changelog/index.html

@@ -495,6 +495,18 @@
   </li>
 
         
+          
+          
+          
+
+
+  <li class="md-nav__item">
+    <a href="../../advanced/remote_execution/" title="Remote Execution" class="md-nav__link">
+      Remote Execution
+    </a>
+  </li>
+
+        
       </ul>
     </nav>
   </li>
@@ -590,8 +602,8 @@
     <ul class="md-nav__list" data-md-scrollfix>
       
         <li class="md-nav__item">
-  <a href="#020-aug-5-2018" title="0.2.0 (Aug 5, 2018)" class="md-nav__link">
-    0.2.0 (Aug 5, 2018)
+  <a href="#021-aug-8-2018" title="0.2.1 (Aug 8, 2018)" class="md-nav__link">
+    0.2.1 (Aug 8, 2018)
   </a>
   
     <nav class="md-nav">
@@ -609,6 +621,33 @@
     Bugfixes
   </a>
   
+</li>
+        
+      </ul>
+    </nav>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#020-aug-5-2018" title="0.2.0 (Aug 5, 2018)" class="md-nav__link">
+    0.2.0 (Aug 5, 2018)
+  </a>
+  
+    <nav class="md-nav">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#features_1" title="Features" class="md-nav__link">
+    Features
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#bugfixes_1" title="Bugfixes" class="md-nav__link">
+    Bugfixes
+  </a>
+  
 </li>
         
           <li class="md-nav__item">
@@ -679,8 +718,8 @@
     <ul class="md-nav__list" data-md-scrollfix>
       
         <li class="md-nav__item">
-  <a href="#020-aug-5-2018" title="0.2.0 (Aug 5, 2018)" class="md-nav__link">
-    0.2.0 (Aug 5, 2018)
+  <a href="#021-aug-8-2018" title="0.2.1 (Aug 8, 2018)" class="md-nav__link">
+    0.2.1 (Aug 8, 2018)
   </a>
   
     <nav class="md-nav">
@@ -698,6 +737,33 @@
     Bugfixes
   </a>
   
+</li>
+        
+      </ul>
+    </nav>
+  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#020-aug-5-2018" title="0.2.0 (Aug 5, 2018)" class="md-nav__link">
+    0.2.0 (Aug 5, 2018)
+  </a>
+  
+    <nav class="md-nav">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#features_1" title="Features" class="md-nav__link">
+    Features
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#bugfixes_1" title="Bugfixes" class="md-nav__link">
+    Bugfixes
+  </a>
+  
 </li>
         
           <li class="md-nav__item">
@@ -737,14 +803,24 @@
                 
                 
                 <h1 id="changelog">Changelog</h1>
-<h2 id="020-aug-5-2018">0.2.0 (Aug 5, 2018)</h2>
+<h2 id="021-aug-8-2018">0.2.1 (Aug 8, 2018)</h2>
 <h3 id="features">Features</h3>
 <ul>
+<li>Remote Execution added for Script and External commands</li>
+</ul>
+<h3 id="bugfixes">Bugfixes</h3>
+<ul>
+<li>Fixed a bug that caused RBCli to crash if a direct path mode script's environment variables were declared as symbols</li>
+</ul>
+<h2 id="020-aug-5-2018">0.2.0 (Aug 5, 2018)</h2>
+<h3 id="features_1">Features</h3>
+<ul>
+<li>CLI tool Autoupdate Enabled; when an upgrade to RBCli is detected, the RBCli CLI tool will notify the developer.</li>
 <li>Official documentation created and hosted with Github Pages</li>
 <li>RBCli released under GPLv3</li>
 <li>Copyright/License notice displayed via RBCli tool with <code>rbcli license</code> in accordance with GPLv3 guidelines</li>
 </ul>
-<h3 id="bugfixes">Bugfixes</h3>
+<h3 id="bugfixes_1">Bugfixes</h3>
 <ul>
 <li>Fixed version number loading for projects</li>
 <li>Cleaned up command usage help output</li>
@@ -753,7 +829,6 @@
 <h3 id="improvements">Improvements</h3>
 <ul>
 <li>A quick reference guide can now be found in README.md</li>
-<li>CLI tool Autoupdate Enabled; when an upgrade to RBCli is detected, the RBCli CLI tool will notify the developer.</li>
 <li>Autoupdate feature now allows supplying a custom message</li>
 <li>Direct Path Mode for External Commands now</li>
 <li>Added support for a <code>lib</code> folder in projects, as a place for custom code, which is automatically added to <code>$LOAD_PATH</code> for developers</li>

data/docs/imported/quick_reference/index.html

@@ -432,6 +432,13 @@
     Automatic Update Check
   </a>
   
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#remote-execution" title="Remote Execution" class="md-nav__link">
+    Remote Execution
+  </a>
+  
 </li>
       
         <li class="md-nav__item">
@@ -641,6 +648,18 @@
   </li>
 
         
+          
+          
+          
+
+
+  <li class="md-nav__item">
+    <a href="../../advanced/remote_execution/" title="Remote Execution" class="md-nav__link">
+      Remote Execution
+    </a>
+  </li>
+
+        
       </ul>
     </nav>
   </li>
@@ -844,6 +863,13 @@
     Automatic Update Check
   </a>
   
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#remote-execution" title="Remote Execution" class="md-nav__link">
+    Remote Execution
+  </a>
+  
 </li>
       
         <li class="md-nav__item">
@@ -964,10 +990,23 @@ log_target 'stderr'
 <h2 id="automatic-update-check">Automatic Update Check</h2>
 <p>RBCli can automatically notify users when an update is available. Two sources are currently supported: Github (including Enterprise) and RubyGems.</p>
 <p>You can configure automatic updates in <code>config/autoupdate.rb</code> in your project.</p>
+<h2 id="remote-execution">Remote Execution</h2>
+<p>RBCli can automatically execute script and extern commands on remote machines via SSH. Enable this feature in <code>config/general.rb</code> by changing the following line to <code>true</code>:</p>
+<pre><code class="ruby">remote_execution permitted: false
+</code></pre>
+
+<p>Then for each command you want to enable remote execution for, add the following directive:</p>
+<pre><code class="ruby">remote_permitted
+</code></pre>
+
+<p>Users can then execute commands remotly by specifying the connection string and credentials on the command line:</p>
+<pre><code class="bash">mytool --remote-exec [user@]host[:port] --identity (/path/to/private/ssh/key or password) &lt;command&gt; ...
+</code></pre>
+
 <h2 id="development-and-contributing">Development and Contributing</h2>
 <p>For more information about development and contributing, please see the <a href="https://akhoury6.github.com/rbcli/development/contributing/">Official Development Documentation</a></p>
 <h2 id="license">License</h2>
-<p>The gem is available as open source under the terms of the <a href="https://github.com/akhoury6/rbcli/blob/master/CODE_OF_CONDUCT.md">GPLv3</a>.</p>
+<p>The gem is available as open source under the terms of the <a href="https://github.com/akhoury6/rbcli/blob/master/LICENSE.txt">GPLv3</a>.</p>
 <h2 id="full-documentation">Full Documentation</h2>
 <p><a href="https://akhoury6.github.com/rbcli">You can find the Official Documentation for RBCli Here.</a></p>
                 

data/docs/index.html

@@ -502,6 +502,18 @@
   </li>
 
         
+          
+          
+          
+
+
+  <li class="md-nav__item">
+    <a href="advanced/remote_execution/" title="Remote Execution" class="md-nav__link">
+      Remote Execution
+    </a>
+  </li>
+
+        
       </ul>
     </nav>
   </li>
@@ -657,6 +669,9 @@
 <li>
 <p><strong>Project Structure and Generators</strong>: Create a well-defined project directory structure which organizes your code and allows you to package and distribute your application as a Gem. Generators can also help speed up the process of creating new commands, scripts, and hooks!</p>
 </li>
+<li>
+<p><strong>Remote Execution</strong>: Automatically execute commands on remote machines via SSH</p>
+</li>
 </ul>
 <p>If you're just getting started with RBCli, take a look at the <a href="tutorial/10-getting_started/">Tutorial</a>. Or take a look at the <a href="advanced/user_config_files/">Advanced</a> menu above to look through RBCli's additional featureset.</p>
                 

data/docs/search/search_index.json

@@ -2,17 +2,17 @@
     "docs": [
         {
             "location": "/", 
-            "text": "This is RBCli\n\n\nAs technologists today, we work with the command line a lot. We script a lot. We write tools to share with each other to make our lives easier. We even write applications to make up for missing features in the 3rd party software that we buy. Unfortunately, when writing CLI tools, this process has typically been very painful. We've been working with low-level frameworks for decades; frameworks like \ngetopt\n (1980) and \ncurses\n (1977). They fit their purpose well; they were both computationally lightweight for the computers of the day, and they gave engineers full control and flexibility when it came to how things were built. Over the years, we've used them to settle on several design patterns that we know work well. Patterns as to what a CLI command looks like, what a config file looks like, what remote execution looks like, and even how to use locks (mutexes, semaphores, etc) to control application flow and data atomicity. Yet we're stuck writing the same low-level code anytime we want to write our tooling. Not anymore.\n\n\nEnter RBCli. RBCli is a framework to quickly develop advanced command-line tools in Ruby. It has been written from the ground up with the needs of the modern technologist in mind, designed to make advanced CLI tool development as painless as possible. In RBCli, low-level code has been wrapped and/or replaced with higher-level methods. Much of the functionality has even been reduced to single methods: for example, it takes just one declaration to define, load, and generate a user's config file at the appropriate times. Many other features are automated and require no work by the engineer. These make RBCli a fundamental re-thining of how we develop CLI tools, enabling the rapid development of applications for everyone from hobbyists to enterprises.\n\n\nSome of its key features include:\n\n\n\n\n\n\nSimple DSL Interface\n: To cut down on the amount of code that needs to be written, RBCli has a DSL that is designed to cut to the chase. This makes the work a lot less tedious.\n\n\n\n\n\n\nMultiple Levels of Parameters and Arguments\n: Forget about writing parsers for command-line options, or about having to differentiate between parameters and arguments. All of that work is taken care of.\n\n\n\n\n\n\nConfig File Generation\n: Easily piece together a default configuration even with declarations in different parts of the code. Then the user can generate their own configuration, and it gets stored in whatever location you'd like.\n\n\n\n\n\n\nMultiple Hooks and Entry Points\n: Define commands, pre-execution hooks, post-execution hooks, and first_run hooks to quickly and easily customize the flow of your application code.\n\n\n\n\n\n\nLogging\n: Keep track of all instances of your tool through logging. Logs can go to STDOUT, STDERR, or a given file, making them compatible with log aggregators such as Splunk, Logstash, and many others.\n\n\n\n\n\n\nLocal State Storage\n: Easily manage a set of data that persists between runs. You get access to a hash that is automatically kept in-sync with a file on disk.\n\n\n\n\n\n\nRemote State\n: It works just like Local State Storage, but store the data on a remote server! It can be used in tandem with Local State Storage or on its own. Currently supports AWS DyanmoDB.  \n\n\n\n\n\n\nState Locking and Sharing\n: Share remote state safely between users with built-in locking! When enabled, it makes sure that only one user is accessing the data at any given time.\n\n\n\n\n\n\nAutomatic Update Notifications\n: Just provide the gem name or git repo, and RBCli will take care of notifying users!\n\n\n\n\n\n\nExternal Script Wrapping\n: High-level wrapping for Bash scripts, or any other applcication you'd like to wrap into a command.\n\n\n\n\n\n\nProject Structure and Generators\n: Create a well-defined project directory structure which organizes your code and allows you to package and distribute your application as a Gem. Generators can also help speed up the process of creating new commands, scripts, and hooks!\n\n\n\n\n\n\nIf you're just getting started with RBCli, take a look at the \nTutorial\n. Or take a look at the \nAdvanced\n menu above to look through RBCli's additional featureset.", 
+            "text": "This is RBCli\n\n\nAs technologists today, we work with the command line a lot. We script a lot. We write tools to share with each other to make our lives easier. We even write applications to make up for missing features in the 3rd party software that we buy. Unfortunately, when writing CLI tools, this process has typically been very painful. We've been working with low-level frameworks for decades; frameworks like \ngetopt\n (1980) and \ncurses\n (1977). They fit their purpose well; they were both computationally lightweight for the computers of the day, and they gave engineers full control and flexibility when it came to how things were built. Over the years, we've used them to settle on several design patterns that we know work well. Patterns as to what a CLI command looks like, what a config file looks like, what remote execution looks like, and even how to use locks (mutexes, semaphores, etc) to control application flow and data atomicity. Yet we're stuck writing the same low-level code anytime we want to write our tooling. Not anymore.\n\n\nEnter RBCli. RBCli is a framework to quickly develop advanced command-line tools in Ruby. It has been written from the ground up with the needs of the modern technologist in mind, designed to make advanced CLI tool development as painless as possible. In RBCli, low-level code has been wrapped and/or replaced with higher-level methods. Much of the functionality has even been reduced to single methods: for example, it takes just one declaration to define, load, and generate a user's config file at the appropriate times. Many other features are automated and require no work by the engineer. These make RBCli a fundamental re-thining of how we develop CLI tools, enabling the rapid development of applications for everyone from hobbyists to enterprises.\n\n\nSome of its key features include:\n\n\n\n\n\n\nSimple DSL Interface\n: To cut down on the amount of code that needs to be written, RBCli has a DSL that is designed to cut to the chase. This makes the work a lot less tedious.\n\n\n\n\n\n\nMultiple Levels of Parameters and Arguments\n: Forget about writing parsers for command-line options, or about having to differentiate between parameters and arguments. All of that work is taken care of.\n\n\n\n\n\n\nConfig File Generation\n: Easily piece together a default configuration even with declarations in different parts of the code. Then the user can generate their own configuration, and it gets stored in whatever location you'd like.\n\n\n\n\n\n\nMultiple Hooks and Entry Points\n: Define commands, pre-execution hooks, post-execution hooks, and first_run hooks to quickly and easily customize the flow of your application code.\n\n\n\n\n\n\nLogging\n: Keep track of all instances of your tool through logging. Logs can go to STDOUT, STDERR, or a given file, making them compatible with log aggregators such as Splunk, Logstash, and many others.\n\n\n\n\n\n\nLocal State Storage\n: Easily manage a set of data that persists between runs. You get access to a hash that is automatically kept in-sync with a file on disk.\n\n\n\n\n\n\nRemote State\n: It works just like Local State Storage, but store the data on a remote server! It can be used in tandem with Local State Storage or on its own. Currently supports AWS DyanmoDB.  \n\n\n\n\n\n\nState Locking and Sharing\n: Share remote state safely between users with built-in locking! When enabled, it makes sure that only one user is accessing the data at any given time.\n\n\n\n\n\n\nAutomatic Update Notifications\n: Just provide the gem name or git repo, and RBCli will take care of notifying users!\n\n\n\n\n\n\nExternal Script Wrapping\n: High-level wrapping for Bash scripts, or any other applcication you'd like to wrap into a command.\n\n\n\n\n\n\nProject Structure and Generators\n: Create a well-defined project directory structure which organizes your code and allows you to package and distribute your application as a Gem. Generators can also help speed up the process of creating new commands, scripts, and hooks!\n\n\n\n\n\n\nRemote Execution\n: Automatically execute commands on remote machines via SSH\n\n\n\n\n\n\nIf you're just getting started with RBCli, take a look at the \nTutorial\n. Or take a look at the \nAdvanced\n menu above to look through RBCli's additional featureset.", 
             "title": "Home"
         }, 
         {
             "location": "/#this-is-rbcli", 
-            "text": "As technologists today, we work with the command line a lot. We script a lot. We write tools to share with each other to make our lives easier. We even write applications to make up for missing features in the 3rd party software that we buy. Unfortunately, when writing CLI tools, this process has typically been very painful. We've been working with low-level frameworks for decades; frameworks like  getopt  (1980) and  curses  (1977). They fit their purpose well; they were both computationally lightweight for the computers of the day, and they gave engineers full control and flexibility when it came to how things were built. Over the years, we've used them to settle on several design patterns that we know work well. Patterns as to what a CLI command looks like, what a config file looks like, what remote execution looks like, and even how to use locks (mutexes, semaphores, etc) to control application flow and data atomicity. Yet we're stuck writing the same low-level code anytime we want to write our tooling. Not anymore.  Enter RBCli. RBCli is a framework to quickly develop advanced command-line tools in Ruby. It has been written from the ground up with the needs of the modern technologist in mind, designed to make advanced CLI tool development as painless as possible. In RBCli, low-level code has been wrapped and/or replaced with higher-level methods. Much of the functionality has even been reduced to single methods: for example, it takes just one declaration to define, load, and generate a user's config file at the appropriate times. Many other features are automated and require no work by the engineer. These make RBCli a fundamental re-thining of how we develop CLI tools, enabling the rapid development of applications for everyone from hobbyists to enterprises.  Some of its key features include:    Simple DSL Interface : To cut down on the amount of code that needs to be written, RBCli has a DSL that is designed to cut to the chase. This makes the work a lot less tedious.    Multiple Levels of Parameters and Arguments : Forget about writing parsers for command-line options, or about having to differentiate between parameters and arguments. All of that work is taken care of.    Config File Generation : Easily piece together a default configuration even with declarations in different parts of the code. Then the user can generate their own configuration, and it gets stored in whatever location you'd like.    Multiple Hooks and Entry Points : Define commands, pre-execution hooks, post-execution hooks, and first_run hooks to quickly and easily customize the flow of your application code.    Logging : Keep track of all instances of your tool through logging. Logs can go to STDOUT, STDERR, or a given file, making them compatible with log aggregators such as Splunk, Logstash, and many others.    Local State Storage : Easily manage a set of data that persists between runs. You get access to a hash that is automatically kept in-sync with a file on disk.    Remote State : It works just like Local State Storage, but store the data on a remote server! It can be used in tandem with Local State Storage or on its own. Currently supports AWS DyanmoDB.      State Locking and Sharing : Share remote state safely between users with built-in locking! When enabled, it makes sure that only one user is accessing the data at any given time.    Automatic Update Notifications : Just provide the gem name or git repo, and RBCli will take care of notifying users!    External Script Wrapping : High-level wrapping for Bash scripts, or any other applcication you'd like to wrap into a command.    Project Structure and Generators : Create a well-defined project directory structure which organizes your code and allows you to package and distribute your application as a Gem. Generators can also help speed up the process of creating new commands, scripts, and hooks!    If you're just getting started with RBCli, take a look at the  Tutorial . Or take a look at the  Advanced  menu above to look through RBCli's additional featureset.", 
+            "text": "As technologists today, we work with the command line a lot. We script a lot. We write tools to share with each other to make our lives easier. We even write applications to make up for missing features in the 3rd party software that we buy. Unfortunately, when writing CLI tools, this process has typically been very painful. We've been working with low-level frameworks for decades; frameworks like  getopt  (1980) and  curses  (1977). They fit their purpose well; they were both computationally lightweight for the computers of the day, and they gave engineers full control and flexibility when it came to how things were built. Over the years, we've used them to settle on several design patterns that we know work well. Patterns as to what a CLI command looks like, what a config file looks like, what remote execution looks like, and even how to use locks (mutexes, semaphores, etc) to control application flow and data atomicity. Yet we're stuck writing the same low-level code anytime we want to write our tooling. Not anymore.  Enter RBCli. RBCli is a framework to quickly develop advanced command-line tools in Ruby. It has been written from the ground up with the needs of the modern technologist in mind, designed to make advanced CLI tool development as painless as possible. In RBCli, low-level code has been wrapped and/or replaced with higher-level methods. Much of the functionality has even been reduced to single methods: for example, it takes just one declaration to define, load, and generate a user's config file at the appropriate times. Many other features are automated and require no work by the engineer. These make RBCli a fundamental re-thining of how we develop CLI tools, enabling the rapid development of applications for everyone from hobbyists to enterprises.  Some of its key features include:    Simple DSL Interface : To cut down on the amount of code that needs to be written, RBCli has a DSL that is designed to cut to the chase. This makes the work a lot less tedious.    Multiple Levels of Parameters and Arguments : Forget about writing parsers for command-line options, or about having to differentiate between parameters and arguments. All of that work is taken care of.    Config File Generation : Easily piece together a default configuration even with declarations in different parts of the code. Then the user can generate their own configuration, and it gets stored in whatever location you'd like.    Multiple Hooks and Entry Points : Define commands, pre-execution hooks, post-execution hooks, and first_run hooks to quickly and easily customize the flow of your application code.    Logging : Keep track of all instances of your tool through logging. Logs can go to STDOUT, STDERR, or a given file, making them compatible with log aggregators such as Splunk, Logstash, and many others.    Local State Storage : Easily manage a set of data that persists between runs. You get access to a hash that is automatically kept in-sync with a file on disk.    Remote State : It works just like Local State Storage, but store the data on a remote server! It can be used in tandem with Local State Storage or on its own. Currently supports AWS DyanmoDB.      State Locking and Sharing : Share remote state safely between users with built-in locking! When enabled, it makes sure that only one user is accessing the data at any given time.    Automatic Update Notifications : Just provide the gem name or git repo, and RBCli will take care of notifying users!    External Script Wrapping : High-level wrapping for Bash scripts, or any other applcication you'd like to wrap into a command.    Project Structure and Generators : Create a well-defined project directory structure which organizes your code and allows you to package and distribute your application as a Gem. Generators can also help speed up the process of creating new commands, scripts, and hooks!    Remote Execution : Automatically execute commands on remote machines via SSH    If you're just getting started with RBCli, take a look at the  Tutorial . Or take a look at the  Advanced  menu above to look through RBCli's additional featureset.", 
             "title": "This is RBCli"
         }, 
         {
             "location": "/imported/quick_reference/", 
-            "text": "Quick Reference\n\n\nInstallation\n\n\nRBCli is available on rubygems.org. You can add it to your application's \nGemfile\n or \ngemspec\n, or install it manually by running:\n\n\ngem install rbcli\n\n\n\n\nThen, \ncd\n to the folder you'd like to create your project under and run:\n\n\nrbcli init -n mytool -d \nA simple CLI tool\n\n\n\n\n\nOr, for a single-file tool without any folder/gem tructure, run \nrbcli init -t mini -n \nprojectname\n or \nrbcli init -t micro -n \nprojectname\n.\n\n\nCreating a command\n\n\nThere are three types of commands: standard, scripted, and external.\n\n\n\n\nStandard\n commands let you code the command directly in Ruby\n\n\nScripted\n commands provide you with a bash script, where all of the parsed information (params, options, args, and config) is shared\n\n\nExternal\n commands let you wrap 3rd party applications directly\n\n\n\n\nStandard Commands\n\n\nTo create a new command called \nfoo\n, run:\n\n\nrbcli command -n foo\n\n\n\n\nYou will now find the command code in \napplication/commands/list.rb\n. Edit the \naction\n block to write your coode.\n\n\nScripted Commands\n\n\nTo create a new scripted command called \nbar\n, run:\n\n\nrbcli script -n bar\n\n\n\n\nYou will then find two new files:\n\n\n\n\nThe command declaration under \napplication/commands/bar.rb\n\n\nThe script code under \napplication/commands/scripts/bar.sh\n\n\n\n\nEdit the script to write your code.\n\n\nExternal Commands\n\n\nTo create a new external command called \nbaz\n, run:\n\n\nrbcli extern -n baz\n\n\n\n\nYou will then find the command code in \napplication/commands/baz.rb\n.\n\n\nUse one of the two provided modes -- direct path mode or variable path mode -- to provide the path to the external program.\n\n\nHooks\n\n\nRBCli has several hooks that run at different points in the exectution chain. They can be created via the \nrbcli\n command line tool:\n\n\nrbcli hook --default      # Runs when no command is provided\nrbcli hook --pre          # Runs before any command\nrbcli hook --post         # Runs after any command\nrbcli hook --firstrun     # Runs the first time a user runs your application. Requires userspace config.\nrbcli hook -dpof          # Create all hooks at once\n\n\n\n\nStorage\n\n\nRBCli supports both local and remote state storage. This is done by synchronizing a Hash with either the local disk or a remote database.\n\n\nLocal State\n\n\nRBCli can provide you with a unique hash that can be persisted to disk on any change to a top-level value.\n\n\nEnable local state in \nconfig/storage.rb\n.\n\n\nThen access it in your Standard Commands with \nRbcli.local_state[:yourkeyhere]\n.\n\n\nRemote State\n\n\nSimilar to the Local State above, RBCli can provide you with a unique hash that can be persisted to a remote storage location.\n\n\nCurrently only AWS DynamoDB is supported, and credentials will be required for each user.\n\n\nEnable remote state in \nconfig/storage.rb\n.\n\n\nThen access it in your Standard Commands with \nRbcli.remote_state[:yourkeyhere]\n.\n\n\nUserspace Configuration Files\n\n\nRBCli provides an easy mechanism to generate and read configuration files from your users. You set the default values and help text with the \ndefaults chain\n, and leverage the \nuser chain\n to read them.\n\n\nYou can set defaults either by placing a YAML file in the \nuserconf/\n folder or by specifying individual options in \napplication/options.rb\n (global) or \napplication/command/*.rb\n (command-specific).\n\n\nUsers can generate a config file, complete with help text, by running your tool with the \n--generate-config\n option.\n\n\nLogging\n\n\nRBCli's logger is configured in \nconfig/logging.rb\n.\n\n\nlog_level :info\nlog_target 'stderr'\n\n\n\n\nThen it can be accessed when writing your commands via:\n\n\nRbcli::log.info { 'These logs can go to STDERR, STDOUT, or a file' }\n\n\n\n\nThe user will also be able to change the log level and target via their config file, if it is enabled.\n\n\nAutomatic Update Check\n\n\nRBCli can automatically notify users when an update is available. Two sources are currently supported: Github (including Enterprise) and RubyGems.\n\n\nYou can configure automatic updates in \nconfig/autoupdate.rb\n in your project.\n\n\nDevelopment and Contributing\n\n\nFor more information about development and contributing, please see the \nOfficial Development Documentation\n\n\nLicense\n\n\nThe gem is available as open source under the terms of the \nGPLv3\n.\n\n\nFull Documentation\n\n\nYou can find the Official Documentation for RBCli Here.", 
+            "text": "Quick Reference\n\n\nInstallation\n\n\nRBCli is available on rubygems.org. You can add it to your application's \nGemfile\n or \ngemspec\n, or install it manually by running:\n\n\ngem install rbcli\n\n\n\n\nThen, \ncd\n to the folder you'd like to create your project under and run:\n\n\nrbcli init -n mytool -d \nA simple CLI tool\n\n\n\n\n\nOr, for a single-file tool without any folder/gem tructure, run \nrbcli init -t mini -n \nprojectname\n or \nrbcli init -t micro -n \nprojectname\n.\n\n\nCreating a command\n\n\nThere are three types of commands: standard, scripted, and external.\n\n\n\n\nStandard\n commands let you code the command directly in Ruby\n\n\nScripted\n commands provide you with a bash script, where all of the parsed information (params, options, args, and config) is shared\n\n\nExternal\n commands let you wrap 3rd party applications directly\n\n\n\n\nStandard Commands\n\n\nTo create a new command called \nfoo\n, run:\n\n\nrbcli command -n foo\n\n\n\n\nYou will now find the command code in \napplication/commands/list.rb\n. Edit the \naction\n block to write your coode.\n\n\nScripted Commands\n\n\nTo create a new scripted command called \nbar\n, run:\n\n\nrbcli script -n bar\n\n\n\n\nYou will then find two new files:\n\n\n\n\nThe command declaration under \napplication/commands/bar.rb\n\n\nThe script code under \napplication/commands/scripts/bar.sh\n\n\n\n\nEdit the script to write your code.\n\n\nExternal Commands\n\n\nTo create a new external command called \nbaz\n, run:\n\n\nrbcli extern -n baz\n\n\n\n\nYou will then find the command code in \napplication/commands/baz.rb\n.\n\n\nUse one of the two provided modes -- direct path mode or variable path mode -- to provide the path to the external program.\n\n\nHooks\n\n\nRBCli has several hooks that run at different points in the exectution chain. They can be created via the \nrbcli\n command line tool:\n\n\nrbcli hook --default      # Runs when no command is provided\nrbcli hook --pre          # Runs before any command\nrbcli hook --post         # Runs after any command\nrbcli hook --firstrun     # Runs the first time a user runs your application. Requires userspace config.\nrbcli hook -dpof          # Create all hooks at once\n\n\n\n\nStorage\n\n\nRBCli supports both local and remote state storage. This is done by synchronizing a Hash with either the local disk or a remote database.\n\n\nLocal State\n\n\nRBCli can provide you with a unique hash that can be persisted to disk on any change to a top-level value.\n\n\nEnable local state in \nconfig/storage.rb\n.\n\n\nThen access it in your Standard Commands with \nRbcli.local_state[:yourkeyhere]\n.\n\n\nRemote State\n\n\nSimilar to the Local State above, RBCli can provide you with a unique hash that can be persisted to a remote storage location.\n\n\nCurrently only AWS DynamoDB is supported, and credentials will be required for each user.\n\n\nEnable remote state in \nconfig/storage.rb\n.\n\n\nThen access it in your Standard Commands with \nRbcli.remote_state[:yourkeyhere]\n.\n\n\nUserspace Configuration Files\n\n\nRBCli provides an easy mechanism to generate and read configuration files from your users. You set the default values and help text with the \ndefaults chain\n, and leverage the \nuser chain\n to read them.\n\n\nYou can set defaults either by placing a YAML file in the \nuserconf/\n folder or by specifying individual options in \napplication/options.rb\n (global) or \napplication/command/*.rb\n (command-specific).\n\n\nUsers can generate a config file, complete with help text, by running your tool with the \n--generate-config\n option.\n\n\nLogging\n\n\nRBCli's logger is configured in \nconfig/logging.rb\n.\n\n\nlog_level :info\nlog_target 'stderr'\n\n\n\n\nThen it can be accessed when writing your commands via:\n\n\nRbcli::log.info { 'These logs can go to STDERR, STDOUT, or a file' }\n\n\n\n\nThe user will also be able to change the log level and target via their config file, if it is enabled.\n\n\nAutomatic Update Check\n\n\nRBCli can automatically notify users when an update is available. Two sources are currently supported: Github (including Enterprise) and RubyGems.\n\n\nYou can configure automatic updates in \nconfig/autoupdate.rb\n in your project.\n\n\nRemote Execution\n\n\nRBCli can automatically execute script and extern commands on remote machines via SSH. Enable this feature in \nconfig/general.rb\n by changing the following line to \ntrue\n:\n\n\nremote_execution permitted: false\n\n\n\n\nThen for each command you want to enable remote execution for, add the following directive:\n\n\nremote_permitted\n\n\n\n\nUsers can then execute commands remotly by specifying the connection string and credentials on the command line:\n\n\nmytool --remote-exec [user@]host[:port] --identity (/path/to/private/ssh/key or password) \ncommand\n ...\n\n\n\n\nDevelopment and Contributing\n\n\nFor more information about development and contributing, please see the \nOfficial Development Documentation\n\n\nLicense\n\n\nThe gem is available as open source under the terms of the \nGPLv3\n.\n\n\nFull Documentation\n\n\nYou can find the Official Documentation for RBCli Here.", 
             "title": "Quick Reference"
         }, 
         {
@@ -80,6 +80,11 @@
             "text": "RBCli can automatically notify users when an update is available. Two sources are currently supported: Github (including Enterprise) and RubyGems.  You can configure automatic updates in  config/autoupdate.rb  in your project.", 
             "title": "Automatic Update Check"
         }, 
+        {
+            "location": "/imported/quick_reference/#remote-execution", 
+            "text": "RBCli can automatically execute script and extern commands on remote machines via SSH. Enable this feature in  config/general.rb  by changing the following line to  true :  remote_execution permitted: false  Then for each command you want to enable remote execution for, add the following directive:  remote_permitted  Users can then execute commands remotly by specifying the connection string and credentials on the command line:  mytool --remote-exec [user@]host[:port] --identity (/path/to/private/ssh/key or password)  command  ...", 
+            "title": "Remote Execution"
+        }, 
         {
             "location": "/imported/quick_reference/#development-and-contributing", 
             "text": "For more information about development and contributing, please see the  Official Development Documentation", 
@@ -272,7 +277,7 @@
         }, 
         {
             "location": "/advanced/command_types/", 
-            "text": "Advanced Command Types\n\n\nRBCli has three different command types:\n\n\n\n\nStandard Commands\n (Ruby-based)\n\n\nScripted Commands\n (Ruby+Bash based)\n\n\nExternal Commands\n (Wrapping a 3rd party application)\n\n\n\n\nThis document is provided to be a reference. If you would like an in-depth tutorial, please see \nYour First Command\n.\n\n\nGeneral Command Structure\n\n\nCommands in RBCli are created by subclassing \nRbcli::Command\n. All commands share a certain common structure:\n\n\nclass List \n Rbcli::Command                                                           # Declare a new command by subclassing Rbcli::Command\n    description 'TODO: Description goes here'                                           # (Required) Short description for the global help\n    usage \n-EOF\nTODO: Usage text goes here\nEOF                                                                                   # (Required) Long description for the command-specific help\n    parameter :force, 'Force testing', type: :boolean, default: false, required: false  # (Optional, Multiple) Add a command-specific CLI parameter. Can be called multiple times\n\n    config_default :myopt2, description: 'My Option #2', default: 'Default Value Here'  # (Optional, Multiple) Specify an individual configuration parameter and set a default value. These will also be included in generated user config.\n                                                                                      # Alternatively, you can simply create a yaml file in the `default_user_configs` directory in your project that specifies the default values of all options\nend\n\n\n\n\n\n\ndescription\n\n\nA short description of the command, which will appear in the top-level help (when the user runs \nmytool -h\n).\n\n\n\n\n\n\nusage\n\n\nA description of how the command is meant to be used. This description can be as long as you want, and can be as in-depth as you'd like. It will show up as a long, multi-line description when the user runs the command-sepcific help (\nmytool list -h\n).\n\n\n\n\n\n\nparameter\n\n\nCommand-line tags that the user can enter that are specific to only this command. We will get into these in the next section on \nOptions, Parameters, and Arguments\n\n\n\n\n\n\nconfig_default\n\n\nThis sets a single item in the config file that will be made available to the user. More information can be found in the documentation on \nUser Config Files\n\n\n\n\n\n\n\n\nStandard Commands\n\n\nStandard commands are written as ruby code. To create a standard command called \nlist\n, run:\n\n\nrbcli command --name=list\n#or\nrbcli command -n list\n\n\n\n\nA standard command can be identified by the presence of an \naction\n block in the definition:\n\n\nclass List \n Rbcli::Command\n    action do |params, args, global_opts, config|\n        # Code goes here\n    end\nend\n\n\n\n\nYour application's \nparameters\n, \narguments\n, \noptions\n, and \nconfig\n are available in the variables passed into the block. For more information on these, see \nOptions, Parameters, and Arguments\n.\n\n\nScripted Commands\n\n\nScripted commands are part Ruby, part Bash scripting. They are a good choice to use if you feel something might be easier or more performant to script with Bash, or if you already have a Bash script you'd like to use in your project. You can create one with:\n\n\nrbcli script -n list\n\n\n\n\nThis will create two files in your RBCli project: a Ruby file with the common command declaration (see \nGeneral Command Structure\n), and a bash script in the folder \napplication/commands/scripts/\n.\n\n\nYou can tell a command is a script by the line:\n\n\nclass List \n Rbcli::Command\n    extern path: :default                                                              # (Required): Do not edit this line. Do delete it if you wish to manually specify a script path and set environment variables.\nend\n\n\n\n\nRBCli will pass along your applications config and CLI parameters through JSON environment variables. To make things easy, a Bash library is provided that makes retrieving and parsing these variables easy. It is already imported when you generate the command, with the line:\n\n\nsource $(echo $(cd \n$(dirname $(gem which rbcli))/../lib-sh\n \n pwd)/lib-rbcli.sh)\n\n\n\n\nThis will find the library which is stored on the system as part of the RBCli gem.\n\n\nYou can then retrieve the values present in your variables like such:\n\n\nrbcli params\nrbcli args\nrbcli global_opts\nrbcli config\nrbcli myvars\n\necho \nUsage Examples:\n\necho \nLog Level:  $(rbcli config .logger.log_level)\n\necho \nLog Target: $(rbcli config .logger.log_target)\n\necho \nFirst Argument (if passed): $(rbcli args .[0])\n\n\n\n\n\nFor your convenience, the script will have all the instructions needed there. For more instructions on how to use JQ syntax to parse values, see the \nJQ documentation\n.\n\n\nExternal Commands\n\n\nExternal Commands are used to wrap 3rd party applications. RBCli accomplishes this by allowing you to set environment variables and command line parameters based on your input variables.\n\n\nRBCli provides this feature through the \nextern\n keyword. It provides two modes -- \ndirect path\n and \nvariable path\n -- which work similarly.\n\n\nDirect Path Mode\n\n\nDirect path mode is the simpler mode of the two External Command modes. It allows you to provide a specific command with environment variables set, though it does not allow using RBCli parameters, arguments, options, and config.\n\n\nruby\nclass List \n Rbcli::Command\n    extern path: 'path/to/application', envvars: {MYVAR: 'some_value'}                               # (Required) Runs a given application, with optional environment variables, when the user runs the command.\nend\n\n\nHere, we supply a string to run the command. We can optioanlly provide environment variables which will be set for the external application.\n\n\nVariable Path Mode\n\n\nVariable Path mode works the same as Direct Path Mode, only instead of providing a string we provide a block that returns a string (which will be the command executed). This allows us to generate different commands based on the CLI parameters that the user passed, or pass configuration as CLI parameters to the external application:\n\n\nclass Test \n Rbcli::Command\n    extern envvars: {MY_OTHER_VAR: 'another_value'} do |params, args, global_opts, config|          # Alternate usage. Supplying a block instead of a path allows us to modify the command based on the arguments and configuration supplied by the user. This allows passing config settings as command line arguments to external applications. The block must return a string, which is the command to be executed.\n        cmd = '/path/to/application'\n        cmd += ' --test-script foo --ignore-errors' if params[:force]\n        cmd\n    end\nend\n\n\n\n\nNOTE\n: Passing user-supplied data as part of the command string may be a security risk (example: \n/path/to/application --name #{params[:name]}\n). It is highly recommended to provide the fixed strings yourself, and only select which strings are used based on the variables provided. This is demonstrated in the example above.", 
+            "text": "Advanced Command Types\n\n\nRBCli has three different command types:\n\n\n\n\nStandard Commands\n (Ruby-based)\n\n\nScripted Commands\n (Ruby+Bash based)\n\n\nExternal Commands\n (Wrapping a 3rd party application)\n\n\n\n\nThis document is provided to be a reference. If you would like an in-depth tutorial, please see \nYour First Command\n.\n\n\nGeneral Command Structure\n\n\nCommands in RBCli are created by subclassing \nRbcli::Command\n. All commands share a certain common structure:\n\n\nclass List \n Rbcli::Command                                                           # Declare a new command by subclassing Rbcli::Command\n    description 'TODO: Description goes here'                                           # (Required) Short description for the global help\n    usage \n-EOF\nTODO: Usage text goes here\nEOF                                                                                   # (Required) Long description for the command-specific help\n    parameter :force, 'Force testing', type: :boolean, default: false, required: false  # (Optional, Multiple) Add a command-specific CLI parameter. Can be called multiple times\n\n    config_default :myopt2, description: 'My Option #2', default: 'Default Value Here'  # (Optional, Multiple) Specify an individual configuration parameter and set a default value. These will also be included in generated user config.\n                                                                                      # Alternatively, you can simply create a yaml file in the `default_user_configs` directory in your project that specifies the default values of all options\nend\n\n\n\n\n\n\ndescription\n\n\nA short description of the command, which will appear in the top-level help (when the user runs \nmytool -h\n).\n\n\n\n\n\n\nusage\n\n\nA description of how the command is meant to be used. This description can be as long as you want, and can be as in-depth as you'd like. It will show up as a long, multi-line description when the user runs the command-sepcific help (\nmytool list -h\n).\n\n\n\n\n\n\nparameter\n\n\nCommand-line tags that the user can enter that are specific to only this command. We will get into these in the next section on \nOptions, Parameters, and Arguments\n\n\n\n\n\n\nconfig_default\n\n\nThis sets a single item in the config file that will be made available to the user. More information can be found in the documentation on \nUser Config Files\n\n\n\n\n\n\n\n\nStandard Commands\n\n\nStandard commands are written as ruby code. To create a standard command called \nlist\n, run:\n\n\nrbcli command --name=list\n#or\nrbcli command -n list\n\n\n\n\nA standard command can be identified by the presence of an \naction\n block in the definition:\n\n\nclass List \n Rbcli::Command\n    action do |params, args, global_opts, config|\n        # Code goes here\n    end\nend\n\n\n\n\nYour application's \nparameters\n, \narguments\n, \noptions\n, and \nconfig\n are available in the variables passed into the block. For more information on these, see \nOptions, Parameters, and Arguments\n.\n\n\nScripted Commands\n\n\nScripted commands are part Ruby, part Bash scripting. They are a good choice to use if you feel something might be easier or more performant to script with Bash, or if you already have a Bash script you'd like to use in your project. You can create one with:\n\n\nrbcli script -n list\n\n\n\n\nThis will create two files in your RBCli project: a Ruby file with the common command declaration (see \nGeneral Command Structure\n), and a bash script in the folder \napplication/commands/scripts/\n.\n\n\nYou can tell a command is a script by the line:\n\n\nclass List \n Rbcli::Command\n    script\nend\n\n\n\n\nRBCli will pass along your applications config and CLI parameters through JSON environment variables. To make things easy, a Bash library is provided that makes retrieving and parsing these variables easy. It is already imported when you generate the command, with the line:\n\n\nsource $(echo $(cd \n$(dirname $(gem which rbcli))/../lib-sh\n \n pwd)/lib-rbcli.sh)\n\n\n\n\nThis will find the library which is stored on the system as part of the RBCli gem.\n\n\nYou can then retrieve the values present in your variables like such:\n\n\nrbcli params\nrbcli args\nrbcli global_opts\nrbcli config\nrbcli myvars\n\necho \nUsage Examples:\n\necho \nLog Level:  $(rbcli config .logger.log_level)\n\necho \nLog Target: $(rbcli config .logger.log_target)\n\necho \nFirst Argument (if passed): $(rbcli args .[0])\n\n\n\n\n\nFor your convenience, the script will have all the instructions needed there. For more instructions on how to use JQ syntax to parse values, see the \nJQ documentation\n.\n\n\nExternal Commands\n\n\nExternal Commands are used to wrap 3rd party applications. RBCli accomplishes this by allowing you to set environment variables and command line parameters based on your input variables.\n\n\nRBCli provides this feature through the \nextern\n keyword. It provides two modes -- \ndirect path\n and \nvariable path\n -- which work similarly.\n\n\nDirect Path Mode\n\n\nDirect path mode is the simpler mode of the two External Command modes. It allows you to provide a specific command with environment variables set, though it does not allow using RBCli parameters, arguments, options, and config.\n\n\nruby\nclass List \n Rbcli::Command\n    extern path: 'path/to/application', envvars: {MYVAR: 'some_value'}                               # (Required) Runs a given application, with optional environment variables, when the user runs the command.\nend\n\n\nHere, we supply a string to run the command. We can optioanlly provide environment variables which will be set for the external application.\n\n\nVariable Path Mode\n\n\nVariable Path mode works the same as Direct Path Mode, only instead of providing a string we provide a block that returns a string (which will be the command executed). This allows us to generate different commands based on the CLI parameters that the user passed, or pass configuration as CLI parameters to the external application:\n\n\nclass Test \n Rbcli::Command\n    extern envvars: {MY_OTHER_VAR: 'another_value'} do |params, args, global_opts, config|          # Alternate usage. Supplying a block instead of a path allows us to modify the command based on the arguments and configuration supplied by the user. This allows passing config settings as command line arguments to external applications. The block must return a string, which is the command to be executed.\n        cmd = '/path/to/application'\n        cmd += ' --test-script foo --ignore-errors' if params[:force]\n        cmd\n    end\nend\n\n\n\n\nNOTE\n: Passing user-supplied data as part of the command string may be a security risk (example: \n/path/to/application --name #{params[:name]}\n). It is highly recommended to provide the fixed strings yourself, and only select which strings are used based on the variables provided. This is demonstrated in the example above.", 
             "title": "Command Types"
         }, 
         {
@@ -292,7 +297,7 @@
         }, 
         {
             "location": "/advanced/command_types/#scripted-commands", 
-            "text": "Scripted commands are part Ruby, part Bash scripting. They are a good choice to use if you feel something might be easier or more performant to script with Bash, or if you already have a Bash script you'd like to use in your project. You can create one with:  rbcli script -n list  This will create two files in your RBCli project: a Ruby file with the common command declaration (see  General Command Structure ), and a bash script in the folder  application/commands/scripts/ .  You can tell a command is a script by the line:  class List   Rbcli::Command\n    extern path: :default                                                              # (Required): Do not edit this line. Do delete it if you wish to manually specify a script path and set environment variables.\nend  RBCli will pass along your applications config and CLI parameters through JSON environment variables. To make things easy, a Bash library is provided that makes retrieving and parsing these variables easy. It is already imported when you generate the command, with the line:  source $(echo $(cd  $(dirname $(gem which rbcli))/../lib-sh    pwd)/lib-rbcli.sh)  This will find the library which is stored on the system as part of the RBCli gem.  You can then retrieve the values present in your variables like such:  rbcli params\nrbcli args\nrbcli global_opts\nrbcli config\nrbcli myvars\n\necho  Usage Examples: \necho  Log Level:  $(rbcli config .logger.log_level) \necho  Log Target: $(rbcli config .logger.log_target) \necho  First Argument (if passed): $(rbcli args .[0])   For your convenience, the script will have all the instructions needed there. For more instructions on how to use JQ syntax to parse values, see the  JQ documentation .", 
+            "text": "Scripted commands are part Ruby, part Bash scripting. They are a good choice to use if you feel something might be easier or more performant to script with Bash, or if you already have a Bash script you'd like to use in your project. You can create one with:  rbcli script -n list  This will create two files in your RBCli project: a Ruby file with the common command declaration (see  General Command Structure ), and a bash script in the folder  application/commands/scripts/ .  You can tell a command is a script by the line:  class List   Rbcli::Command\n    script\nend  RBCli will pass along your applications config and CLI parameters through JSON environment variables. To make things easy, a Bash library is provided that makes retrieving and parsing these variables easy. It is already imported when you generate the command, with the line:  source $(echo $(cd  $(dirname $(gem which rbcli))/../lib-sh    pwd)/lib-rbcli.sh)  This will find the library which is stored on the system as part of the RBCli gem.  You can then retrieve the values present in your variables like such:  rbcli params\nrbcli args\nrbcli global_opts\nrbcli config\nrbcli myvars\n\necho  Usage Examples: \necho  Log Level:  $(rbcli config .logger.log_level) \necho  Log Target: $(rbcli config .logger.log_target) \necho  First Argument (if passed): $(rbcli args .[0])   For your convenience, the script will have all the instructions needed there. For more instructions on how to use JQ syntax to parse values, see the  JQ documentation .", 
             "title": "Scripted Commands"
         }, 
         {
@@ -435,9 +440,29 @@
             "text": "Remember: all state in Rbcli is lazy-loaded. Therefore, RBCli wll only attempt to lock the data when you first try to access it. If you need to make sure that the data is locked before executing a block of code, use:  Rbcli.remote_state.refresh  to force the lock and retrieve the latest data. You can force an unlock by calling:  Rbcli.remote_state.disconnect  Even if you do not want to store any data, you can leverage manual locking to control access to a different shared resource, such as a stateful API. For example, if you write a cloud deployment toolkit, you can ensure that only one user is attempting to modify a deployment at any given time.", 
             "title": "Manual Locking"
         }, 
+        {
+            "location": "/advanced/remote_execution/", 
+            "text": "Remote Execution\n\n\nRBCli can be configured to execute commands on a remote machine via SSH instead of locally.\n\n\nCurrently, only \nscript\n and \nextern\n commands are supported.\n\n\nConfiguration\n\n\nTo allow remote execution, go to \nconfig/general.rb\n and change the following line to \ntrue\n:\n\n\nremote_execution permitted: false\n\n\n\n\nThen, for each command that you would like to enable remote execution for, add the following directive to the command class declaration:\n\n\nremote_permitted\n\n\n\n\nUsage\n\n\nYour end users can now execute a command remotely by specifying the connection string and credentials on the command line as follows:\n\n\nmytool --remote-exec [user@]host[:port] --identity (/path/to/private/ssh/key or password) \ncommand\n\n# or\nmytool -r [user@]host[:port] -i (/path/to/private/ssh/key or password) \ncommand\n\n\n\n\n\nSome valid examples are:\n\n\nmytool -r example.com -i myPassword showuserfiles -u MyUser\nmytool -r root@server.local -i ~/.ssh/id_rsa update\nmytool -r admin@172.16.0.1:2202 -i ~/.ssh/mykey cleartemp\n\n\n\n\nIf the end user is unsure of which commands can or can not be executed remotely, they can check by running \nmytool -h\n. Commands that have remote execution enabled will have an asterisk (*) by their name:\n\n\n$ mytool -h\nA simple command line tool.\nFor more information on individual commands, run `mytool \ncommand\n -h`.\n\nUsage:\n      foo [options] command [parameters]\n\nCommands:\n      bar                  TODO: Description goes here\n   *  baz                  TODO: Description goes here\n\n...\n\n\n\n\nIn this example, the command \nbaz\n is available for remote execution", 
+            "title": "Remote Execution"
+        }, 
+        {
+            "location": "/advanced/remote_execution/#remote-execution", 
+            "text": "RBCli can be configured to execute commands on a remote machine via SSH instead of locally.  Currently, only  script  and  extern  commands are supported.", 
+            "title": "Remote Execution"
+        }, 
+        {
+            "location": "/advanced/remote_execution/#configuration", 
+            "text": "To allow remote execution, go to  config/general.rb  and change the following line to  true :  remote_execution permitted: false  Then, for each command that you would like to enable remote execution for, add the following directive to the command class declaration:  remote_permitted", 
+            "title": "Configuration"
+        }, 
+        {
+            "location": "/advanced/remote_execution/#usage", 
+            "text": "Your end users can now execute a command remotely by specifying the connection string and credentials on the command line as follows:  mytool --remote-exec [user@]host[:port] --identity (/path/to/private/ssh/key or password)  command \n# or\nmytool -r [user@]host[:port] -i (/path/to/private/ssh/key or password)  command   Some valid examples are:  mytool -r example.com -i myPassword showuserfiles -u MyUser\nmytool -r root@server.local -i ~/.ssh/id_rsa update\nmytool -r admin@172.16.0.1:2202 -i ~/.ssh/mykey cleartemp  If the end user is unsure of which commands can or can not be executed remotely, they can check by running  mytool -h . Commands that have remote execution enabled will have an asterisk (*) by their name:  $ mytool -h\nA simple command line tool.\nFor more information on individual commands, run `mytool  command  -h`.\n\nUsage:\n      foo [options] command [parameters]\n\nCommands:\n      bar                  TODO: Description goes here\n   *  baz                  TODO: Description goes here\n\n...  In this example, the command  baz  is available for remote execution", 
+            "title": "Usage"
+        }, 
         {
             "location": "/development/contributing/", 
-            "text": "Contribution Guide\n\n\nContributing to RBCli is the same as most open source projects:\n\n\n\n\nFork the repository\n\n\nCreate your own branch\n\n\nSubmit a pull request when ready\n\n\n\n\nThat's all there is to it! We've also kept our acceptance criteria pretty simple, as you'll see below. Feel free to submit a pull request even if you don't meet it if you would like your code or feature to be reviewed first; we do want to be mindful of your time and will review submissions before they are polished.\n\n\nCode Acceptance Criteria\n\n\nTabs, Not Spaces\n\n\nPlease, and thanks. We all like to use different indentation levels and styles, and this will keep us consistent between editors.\n\n\nFor filetypes where tabs are not supported (such as YAML), please stick to using two (2) spaces.\n\n\nDocumentation for User Features\n\n\nFor any modification that alters the way RBCli is used -- we're talking additional features, options, keyword changes, major behavioral changes, and the like -- the documentation will need to be updated as well. You'll be happy to know we designed it to make the process relatively painless.\n\n\nRBCli's documentation is essentially a collection of markdown files that have been compiled into a static site using \nMkDocs\n. If you already have python and pip on your system, you can install it by running:\n\n\npip install mkdocs mkdocs-material\n\n\n\n\nYou can find the source markdown files in the \ndocs-src/docs\n folder, and the menu organization in \ndocs-src/mkdocs.yml\n. To preview your changes on a live site, run:\n\n\nmkdocs serve\n\n\n\n\nAlso, don't forget to update the \nQuick Reference Guide\n in the \nREADME.md\n file (the main project one) with information about your changes.\n\n\nOnce you've completed your edits, run the \nmakesite.sh\n command to build the actual HTML pages automatically in the \ndocs\n folder, from where they will be served when live.\n\n\nMaintainer's Notes\n\n\nTo install this gem onto your local machine from source, run \nbundle exec rake install\n.\n\n\nTo release a new version, follow theese steps:\n\n\n\n\nUpdate the version number in \nversion.rb\n\n\nRun \nbundle exec rake install\n, which will update \ngemfile.lock\n with the correct version and all dependency changes\n\n\nRun \ndocs-src/makesite.sh\n, which re-compiles the documentation and pulls in the changelog and quick reference automatically\n\n\nCommit the above changes to master, but do not push\n\n\nRun \nbundle exec rake release\n, which will create a git tag for the version, push git commits and tags, and push the \n.gem\n file to \nrubygems.org\n.", 
+            "text": "Contribution Guide\n\n\nContributing to RBCli is the same as most open source projects:\n\n\n\n\nFork the repository\n\n\nCreate your own branch\n\n\nSubmit a pull request when ready\n\n\n\n\nThat's all there is to it! We've also kept our acceptance criteria pretty simple, as you'll see below. Feel free to submit a pull request even if you don't meet it if you would like your code or feature to be reviewed first; we do want to be mindful of your time and will review submissions before they are polished.\n\n\nCode Acceptance Criteria\n\n\nTabs, Not Spaces\n\n\nPlease, and thanks. We all like to use different indentation levels and styles, and this will keep us consistent between editors.\n\n\nFor filetypes where tabs are not supported (such as YAML), please stick to using two (2) spaces.\n\n\nDocumentation for User Features\n\n\nFor any modification that alters the way RBCli is used -- we're talking additional features, options, keyword changes, major behavioral changes, and the like -- the documentation will need to be updated as well. You'll be happy to know we designed it to make the process relatively painless.\n\n\nRBCli's documentation is essentially a collection of markdown files that have been compiled into a static site using \nMkDocs\n. If you already have python and pip on your system, you can install it by running:\n\n\npip install mkdocs mkdocs-material\n\n\n\n\nYou can find the source markdown files in the \ndocs-src/docs\n folder, and the menu organization in \ndocs-src/mkdocs.yml\n. To preview your changes on a live site, run:\n\n\nmkdocs serve\n\n\n\n\nAlso, don't forget to update the \nQuick Reference Guide\n in the \nREADME.md\n file (the main project one) with information about your changes.\n\n\nOnce you've completed your edits, run the \nmakesite.sh\n command to build the actual HTML pages automatically in the \ndocs\n folder, from where they will be served when live.\n\n\nMaintainer's Notes\n\n\nTo install this gem onto your local machine from source, run \nbundle exec rake install\n.\n\n\nTo release a new version, follow theese steps:\n\n\n\n\nUpdate the version number in \nversion.rb\n\n\nRun \nbundle exec rake install\n, which will update \ngemfile.lock\n with the correct version and all dependency changes\n\n\nRun \ndocs-src/makesite.sh\n, which re-compiles the documentation and pulls in the changelog and quick reference automatically\n\n\nCommit the above changes to master with a commit message of \"vX.X.X\" (where X.X.X is the version number), but do not push\n\n\nRun \nbundle exec rake release\n, which will create a git tag for the version, push git commits and tags, and push the \n.gem\n file to \nrubygems.org\n.", 
             "title": "Contribution Guide"
         }, 
         {
@@ -462,7 +487,7 @@
         }, 
         {
             "location": "/development/contributing/#maintainers-notes", 
-            "text": "To install this gem onto your local machine from source, run  bundle exec rake install .  To release a new version, follow theese steps:   Update the version number in  version.rb  Run  bundle exec rake install , which will update  gemfile.lock  with the correct version and all dependency changes  Run  docs-src/makesite.sh , which re-compiles the documentation and pulls in the changelog and quick reference automatically  Commit the above changes to master, but do not push  Run  bundle exec rake release , which will create a git tag for the version, push git commits and tags, and push the  .gem  file to  rubygems.org .", 
+            "text": "To install this gem onto your local machine from source, run  bundle exec rake install .  To release a new version, follow theese steps:   Update the version number in  version.rb  Run  bundle exec rake install , which will update  gemfile.lock  with the correct version and all dependency changes  Run  docs-src/makesite.sh , which re-compiles the documentation and pulls in the changelog and quick reference automatically  Commit the above changes to master with a commit message of \"vX.X.X\" (where X.X.X is the version number), but do not push  Run  bundle exec rake release , which will create a git tag for the version, push git commits and tags, and push the  .gem  file to  rubygems.org .", 
             "title": "Maintainer's Notes"
         }, 
         {
@@ -522,7 +547,7 @@
         }, 
         {
             "location": "/imported/changelog/", 
-            "text": "Changelog\n\n\n0.2.0 (Aug 5, 2018)\n\n\nFeatures\n\n\n\n\nOfficial documentation created and hosted with Github Pages\n\n\nRBCli released under GPLv3\n\n\nCopyright/License notice displayed via RBCli tool with \nrbcli license\n in accordance with GPLv3 guidelines\n\n\n\n\nBugfixes\n\n\n\n\nFixed version number loading for projects\n\n\nCleaned up command usage help output\n\n\nFixed script and external command generation\n\n\n\n\nImprovements\n\n\n\n\nA quick reference guide can now be found in README.md\n\n\nCLI tool Autoupdate Enabled; when an upgrade to RBCli is detected, the RBCli CLI tool will notify the developer.\n\n\nAutoupdate feature now allows supplying a custom message\n\n\nDirect Path Mode for External Commands now\n\n\nAdded support for a \nlib\n folder in projects, as a place for custom code, which is automatically added to \n$LOAD_PATH\n for developers\n\n\nImproved language regarding external commands: Documentation now differentiates between Standard, Scripted, and External Commands\n\n\nImproved language regarding user config files: Now called Userspace Config\n\n\nOptions and Parameters now allow specifying the letter to be used for the short version, or to disable it altogether\n\n\nUserspace config can now be disabled by setting the path to nil or removing the declaration\n\n\n\n\nDeprecations/Changes\n\n\n\n\nRemoved deprecated and broken examples from the examples folder", 
+            "text": "Changelog\n\n\n0.2.1 (Aug 8, 2018)\n\n\nFeatures\n\n\n\n\nRemote Execution added for Script and External commands\n\n\n\n\nBugfixes\n\n\n\n\nFixed a bug that caused RBCli to crash if a direct path mode script's environment variables were declared as symbols\n\n\n\n\n0.2.0 (Aug 5, 2018)\n\n\nFeatures\n\n\n\n\nCLI tool Autoupdate Enabled; when an upgrade to RBCli is detected, the RBCli CLI tool will notify the developer.\n\n\nOfficial documentation created and hosted with Github Pages\n\n\nRBCli released under GPLv3\n\n\nCopyright/License notice displayed via RBCli tool with \nrbcli license\n in accordance with GPLv3 guidelines\n\n\n\n\nBugfixes\n\n\n\n\nFixed version number loading for projects\n\n\nCleaned up command usage help output\n\n\nFixed script and external command generation\n\n\n\n\nImprovements\n\n\n\n\nA quick reference guide can now be found in README.md\n\n\nAutoupdate feature now allows supplying a custom message\n\n\nDirect Path Mode for External Commands now\n\n\nAdded support for a \nlib\n folder in projects, as a place for custom code, which is automatically added to \n$LOAD_PATH\n for developers\n\n\nImproved language regarding external commands: Documentation now differentiates between Standard, Scripted, and External Commands\n\n\nImproved language regarding user config files: Now called Userspace Config\n\n\nOptions and Parameters now allow specifying the letter to be used for the short version, or to disable it altogether\n\n\nUserspace config can now be disabled by setting the path to nil or removing the declaration\n\n\n\n\nDeprecations/Changes\n\n\n\n\nRemoved deprecated and broken examples from the examples folder", 
             "title": "Changelog"
         }, 
         {
@@ -531,23 +556,38 @@
             "title": "Changelog"
         }, 
         {
-            "location": "/imported/changelog/#020-aug-5-2018", 
+            "location": "/imported/changelog/#021-aug-8-2018", 
             "text": "", 
-            "title": "0.2.0 (Aug 5, 2018)"
+            "title": "0.2.1 (Aug 8, 2018)"
         }, 
         {
             "location": "/imported/changelog/#features", 
-            "text": "Official documentation created and hosted with Github Pages  RBCli released under GPLv3  Copyright/License notice displayed via RBCli tool with  rbcli license  in accordance with GPLv3 guidelines", 
+            "text": "Remote Execution added for Script and External commands", 
             "title": "Features"
         }, 
         {
             "location": "/imported/changelog/#bugfixes", 
+            "text": "Fixed a bug that caused RBCli to crash if a direct path mode script's environment variables were declared as symbols", 
+            "title": "Bugfixes"
+        }, 
+        {
+            "location": "/imported/changelog/#020-aug-5-2018", 
+            "text": "", 
+            "title": "0.2.0 (Aug 5, 2018)"
+        }, 
+        {
+            "location": "/imported/changelog/#features_1", 
+            "text": "CLI tool Autoupdate Enabled; when an upgrade to RBCli is detected, the RBCli CLI tool will notify the developer.  Official documentation created and hosted with Github Pages  RBCli released under GPLv3  Copyright/License notice displayed via RBCli tool with  rbcli license  in accordance with GPLv3 guidelines", 
+            "title": "Features"
+        }, 
+        {
+            "location": "/imported/changelog/#bugfixes_1", 
             "text": "Fixed version number loading for projects  Cleaned up command usage help output  Fixed script and external command generation", 
             "title": "Bugfixes"
         }, 
         {
             "location": "/imported/changelog/#improvements", 
-            "text": "A quick reference guide can now be found in README.md  CLI tool Autoupdate Enabled; when an upgrade to RBCli is detected, the RBCli CLI tool will notify the developer.  Autoupdate feature now allows supplying a custom message  Direct Path Mode for External Commands now  Added support for a  lib  folder in projects, as a place for custom code, which is automatically added to  $LOAD_PATH  for developers  Improved language regarding external commands: Documentation now differentiates between Standard, Scripted, and External Commands  Improved language regarding user config files: Now called Userspace Config  Options and Parameters now allow specifying the letter to be used for the short version, or to disable it altogether  Userspace config can now be disabled by setting the path to nil or removing the declaration", 
+            "text": "A quick reference guide can now be found in README.md  Autoupdate feature now allows supplying a custom message  Direct Path Mode for External Commands now  Added support for a  lib  folder in projects, as a place for custom code, which is automatically added to  $LOAD_PATH  for developers  Improved language regarding external commands: Documentation now differentiates between Standard, Scripted, and External Commands  Improved language regarding user config files: Now called Userspace Config  Options and Parameters now allow specifying the letter to be used for the short version, or to disable it altogether  Userspace config can now be disabled by setting the path to nil or removing the declaration", 
             "title": "Improvements"
         }, 
         {