update all shell output to console lexer

Author: schacon

atlas.json

@@ -25,7 +25,7 @@
       "version": "web",
       "index": true,
       "toc": true,
-      "syntaxhighlighting": false,
+      "syntaxhighlighting": true,
       "show_comments": false
     },
     "epub": {
@@ -62,7 +62,8 @@
       "toc": true,
       "syntaxhighlighting": false,
       "show_comments": false,
-      "consolidate": false
+      "consolidate": false,
+      "consolidated": false
     }
   },
   "theme": "oreillymedia/atlas_tech1c_theme",

book/02-git-basics/sections/aliases.asc

@@ -9,7 +9,7 @@ Git doesn't automatically infer your command if you type it in partially.
 If you don't want to type the entire text of each of the Git commands, you can easily set up an alias for each command using `git config`.(((git commands, config)))
 Here are a couple of examples you may want to set up:
 
-[source,shell]
+[source,console]
 ----
 $ git config --global alias.co checkout
 $ git config --global alias.br branch
@@ -23,14 +23,14 @@ As you go on using Git, you'll probably use other commands frequently as well; d
 This technique can also be very useful in creating commands that you think should exist.
 For example, to correct the usability problem you encountered with unstaging a file, you can add your own unstage alias to Git:
 
-[source,shell]
+[source,console]
 ----
 $ git config --global alias.unstage 'reset HEAD --'
 ----
 
 This makes the following two commands equivalent:
 
-[source,shell]
+[source,console]
 ----
 $ git unstage fileA
 $ git reset HEAD fileA
@@ -39,14 +39,14 @@ $ git reset HEAD fileA
 This seems a bit clearer.
 It's also common to add a `last` command, like this:
 
-[source,shell]
+[source,console]
 ----
 $ git config --global alias.last 'log -1 HEAD'
 ----
 
 This way, you can see the last commit easily:
 
-[source,shell]
+[source,console]
 ----
 $ git last
 commit 66938dae3329c7aebe598c2246a8e6af90d04646
@@ -64,7 +64,7 @@ In that case, you start the command with a `!` character.
 This is useful if you write your own tools that work with a Git repository.
 We can demonstrate by aliasing `git visual` to run `gitk`:
 
-[source,shell]
+[source,console]
 ----
 $ git config --global alias.visual "!gitk"
 ----

book/02-git-basics/sections/getting-a-repository.asc

@@ -9,7 +9,7 @@ The second clones an existing Git repository from another server.
 
 If you're starting to track an existing project in Git, you need to go to the project's directory and type
 
-[source,shell]
+[source,console]
 ----
 $ git init
 ----
@@ -21,7 +21,7 @@ At this point, nothing in your project is tracked yet.
 If you want to start version-controlling existing files (as opposed to an empty directory), you should probably begin tracking those files and do an initial commit.
 You can accomplish that with a few `git add` commands that specify the files you want to track, followed by a `git commit`:
 
-[source,shell]
+[source,console]
 ----
 $ git add *.c
 $ git add LICENSE
@@ -43,7 +43,7 @@ In fact, if your server disk gets corrupted, you can often use nearly any of the
 You clone a repository with `git clone [url]`.(((git commands, clone)))
 For example, if you want to clone the Git linkable library called libgit2, you can do so like this:
 
-[source,shell]
+[source,console]
 ----
 $ git clone https://github.com/libgit2/libgit2
 ----
@@ -52,7 +52,7 @@ That creates a directory named ``libgit2'', initializes a `.git` directory insid
 If you go into the new `libgit2` directory, you'll see the project files in there, ready to be worked on or used.
 If you want to clone the repository into a directory named something other than ``libgit2'', you can specify that as the next command-line option:
 
-[source,shell]
+[source,console]
 ----
 $ git clone https://github.com/libgit2/libgit2 mylibgit
 ----

book/02-git-basics/sections/recording-changes.asc

@@ -20,7 +20,7 @@ image::images/lifecycle.png[The lifecycle of the status of your files.]
 The main tool you use to determine which files are in which state is the `git status` command.(((git commands, status)))
 If you run this command directly after a clone, you should see something like this:
 
-[source,shell]
+[source,console]
 ----
 $ git status
 On branch master
@@ -36,7 +36,7 @@ For now, that branch is always ``master'', which is the default; you won't worry
 Let's say you add a new file to your project, a simple README file.
 If the file didn't exist before, and you run `git status`, you see your untracked file like so:
 
-[source,shell]
+[source,console]
 ----
 $ echo 'My Project' > README
 $ git status
@@ -60,14 +60,14 @@ You do want to start including README, so let's start tracking the file.
 In order to begin tracking a new file, you use the command `git add`.(((git commands, add)))
 To begin tracking the README file, you can run this:
 
-[source,shell]
+[source,console]
 ----
 $ git add README
 ----
 
 If you run your status command again, you can see that your README file is now tracked and staged to be committed:
 
-[source,shell]
+[source,console]
 ----
 $ git status
 On branch master
@@ -88,7 +88,7 @@ The `git add` command takes a path name for either a file or a directory; if it'
 Let's change a file that was already tracked.
 If you change a previously tracked file called ``benchmarks.rb'' and then run your `git status` command again, you get something that looks like this:
 
-[source,shell]
+[source,console]
 ----
 $ git status
 On branch master
@@ -109,7 +109,7 @@ The ``benchmarks.rb'' file appears under a section named ``Changed but not stage
 To stage it, you run the `git add` command. `git add` is a multipurpose command – you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved. It may be helpful to think of it more as ``add this content to the next commit'' rather than ``add this file to the project''.(((git commands, add)))
 Let's run `git add` now to stage the ``benchmarks.rb'' file, and then run `git status` again:
 
-[source,shell]
+[source,console]
 ----
 $ git add benchmarks.rb
 $ git status
@@ -127,7 +127,7 @@ At this point, suppose you remember one little change that you want to make in `
 You open it again and make that change, and you're ready to commit.
 However, let's run `git status` one more time:
 
-[source,shell]
+[source,console]
 ----
 $ vim benchmarks.rb
 $ git status
@@ -153,7 +153,7 @@ It turns out that Git stages a file exactly as it is when you run the `git add`
 If you commit now, the version of `benchmarks.rb` as it was when you last ran the `git add` command is how it will go into the commit, not the version of the file as it looks in your working directory when you run `git commit`.
 If you modify a file after you run `git add`, you have to run `git add` again to stage the latest version of the file:
 
-[source,shell]
+[source,console]
 ----
 $ git add benchmarks.rb
 $ git status
@@ -169,7 +169,7 @@ Changes to be committed:
 
 While the `git status` output is pretty comprehensive, it's also quite wordy. Git also has a short status flag so you can see your changes in a more compact way. If you run `git status -s` or `git status --short` you get a far more simplified output from the command.
 
-[source,shell]
+[source,console]
 ----
 $ git status -s
  M README
@@ -189,7 +189,7 @@ These are generally automatically generated files such as log files or files pro
 In such cases, you can create a file listing patterns to match them named `.gitignore`.(((ignoring files)))
 Here is an example `.gitignore` file:
 
-[source,shell]
+[source,console]
 ----
 $ cat .gitignore
 *.[oa]
@@ -214,7 +214,7 @@ You can also use two asterisks to match nested directories; `a/**/z` would match
 
 Here is another example .gitignore file:
 
-[source,shell]
+[source,console]
 ----
 # a comment - this is ignored
 *.a       # no .a files
@@ -240,7 +240,7 @@ Although `git status` answers those questions very generally by listing the file
 Let's say you edit and stage the `README` file again and then edit the `benchmarks.rb` file without staging it.
 If you run your `git status` command, you once again see something like this:
 
-[source,shell]
+[source,console]
 ----
 $ git status
 On branch master
@@ -258,7 +258,7 @@ Changes not staged for commit:
 
 To see what you've changed but not yet staged, type `git diff` with no other arguments:
 
-[source,shell]
+[source,console]
 ----
 $ git diff
 diff --git a/benchmarks.rb b/benchmarks.rb
@@ -284,7 +284,7 @@ The result tells you the changes you've made that you haven't yet staged.
 If you want to see what you've staged that will go into your next commit, you can use `git diff --staged`.
 This command compares your staged changes to your last commit:
 
-[source,shell]
+[source,console]
 ----
 $ git diff --staged
 diff --git a/README b/README
@@ -304,7 +304,7 @@ This can be confusing, because if you've staged all of your changes, `git diff`
 
 For another example, if you stage the `benchmarks.rb` file and then edit it, you can use `git diff` to see the changes in the file that are staged and the changes that are unstaged:
 
-[source,shell]
+[source,console]
 ----
 $ git add benchmarks.rb
 $ echo '# test line' >> benchmarks.rb
@@ -324,7 +324,7 @@ Changes not staged for commit:
 
 Now you can use `git diff` to see what is still unstaged
 
-[source,shell]
+[source,console]
 ----
 $ git diff
 diff --git a/benchmarks.rb b/benchmarks.rb
@@ -340,7 +340,7 @@ index e445e28..86b2f7c 100644
 
 and `git diff --cached` to see what you've staged so far:
 
-[source,shell]
+[source,console]
 ----
 $ git diff --cached
 diff --git a/benchmarks.rb b/benchmarks.rb
@@ -369,7 +369,7 @@ They will stay as modified files on your disk.
 In this case, let's say that the last time you ran `git status`, you saw that everything was staged, so you're ready to commit your changes.(((git commands, status)))
 The simplest way to commit is to type `git commit`:(((git commands, commit)))
 
-[source,shell]
+[source,console]
 ----
 $ git commit
 ----
@@ -379,7 +379,7 @@ Doing so launches your editor of choice.
 
 The editor displays the following text (this example is a Vim screen):
 
-[source,shell]
+[source,console]
 ----
 
 # Please enter the commit message for your changes. Lines starting
@@ -403,7 +403,7 @@ When you exit the editor, Git creates your commit with that commit message (with
 
 Alternatively, you can type your commit message inline with the `commit` command by specifying it after a -m flag, like this:
 
-[source,shell]
+[source,console]
 ----
 $ git commit -m "Story 182: Fix benchmarks for speed"
 [master 463dc4f] Story 182: Fix benchmarks for speed
@@ -425,7 +425,7 @@ Although it can be amazingly useful for crafting commits exactly how you want th
 If you want to skip the staging area, Git provides a simple shortcut.
 Adding the `-a` option to the `git commit` command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the `git add` part:
 
-[source,shell]
+[source,console]
 ----
 $ git status
 On branch master
@@ -452,7 +452,7 @@ The `git rm` command does that, and also removes the file from your working dire
 
 If you simply remove the file from your working directory, it shows up under the ``Changed but not updated'' (that is, _unstaged_) area of your `git status` output:
 
-[source,shell]
+[source,console]
 ----
 $ rm grit.gemspec
 $ git status
@@ -468,7 +468,7 @@ no changes added to commit (use "git add" and/or "git commit -a")
 
 Then, if you run `git rm`, it stages the file's removal:
 
-[source,shell]
+[source,console]
 ----
 $ git rm grit.gemspec
 rm 'grit.gemspec'
@@ -489,15 +489,15 @@ In other words, you may want to keep the file on your hard drive but not have Gi
 This is particularly useful if you forgot to add something to your `.gitignore` file and accidentally added it, like a large log file or a bunch of `.a` compiled files.
 To do this, use the `--cached` option:
 
-[source,shell]
+[source,console]
 ----
 $ git rm --cached README
 ----
 
 You can pass files, directories, and file-glob patterns to the `git rm` command.
 That means you can do things such as
 
-[source,shell]
+[source,console]
 ----
 $ git rm log/\*.log
 ----
@@ -507,7 +507,7 @@ This is necessary because Git does its own filename expansion in addition to you
 This command removes all files that have the `.log` extension in the `log/` directory.
 Or, you can do something like this:
 
-[source,shell]
+[source,console]
 ----
 $ git rm \*~
 ----
@@ -525,15 +525,15 @@ However, Git is pretty smart about figuring that out after the fact – we'll de
 Thus it's a bit confusing that Git has a `mv` command.
 If you want to rename a file in Git, you can run something like
 
-[source,shell]
+[source,console]
 ----
 $ git mv file_from file_to
 ----
 
 and it works fine.
 In fact, if you run something like this and look at the status, you'll see that Git considers it a renamed file:
 
-[source,shell]
+[source,console]
 ----
 $ git mv README.md README
 $ git status
@@ -546,7 +546,7 @@ Changes to be committed:
 
 However, this is equivalent to running something like this:
 
-[source,shell]
+[source,console]
 ----
 $ mv README.md README
 $ git rm README.md