fix usage examples and more to use new invocations

Signed-off-by: Carl Lerche <carllerche@mac.com>

13 files changed, 106 insertions, 106 deletions

diff --git a/railties/guides/source/3_0_release_notes.textile b/railties/guides/source/3_0_release_notes.textile
index 5e96f8cf06..1624172176 100644
--- a/railties/guides/source/3_0_release_notes.textile
+++ b/railties/guides/source/3_0_release_notes.textile
@@ -39,8 +39,8 @@ h4. script/* replaced by script/rails
 The new <tt>script/rails</tt> replaces all the scripts that used to be in the <tt>script</tt> directory. You do not run <tt>script/rails</tt> directly though, the +rails+ command detects it is being invoked in the root of a Rails application and runs the script for you. Intended usage is:
 
 <shell>
-rails console                      # => ./script/console
-rails g scaffold post title:string # => ./script/generate scaffold post title:string
+rails console                      # => ./script/rails console
+rails g scaffold post title:string # => ./script/rails generate scaffold post title:string
 </shell>
 
 Run rails --help for a list of all the options.
@@ -557,4 +557,4 @@ h3. Credits
 
 See the "full list of contributors to Rails":http://contributors.rubyonrails.org/ for the many people who spent many hours making Rails 3.  Kudos to all of them.
 
-Rails 3.0 Release Notes were compiled by "Mikel Lindsaar":http://lindsaar.net.
\ No newline at end of file
+Rails 3.0 Release Notes were compiled by "Mikel Lindsaar":http://lindsaar.net.
diff --git a/railties/guides/source/action_mailer_basics.textile b/railties/guides/source/action_mailer_basics.textile
index 2405b8f28c..941c2e9771 100644
--- a/railties/guides/source/action_mailer_basics.textile
+++ b/railties/guides/source/action_mailer_basics.textile
@@ -19,7 +19,7 @@ h4. Walkthrough to Generating a Mailer
 h5. Create the Mailer
 
 <shell>
-./script/generate mailer UserMailer
+rails generate mailer UserMailer
 create  app/mailers/user_mailer.rb
 invoke  erb
 create    app/views/user_mailer
@@ -111,7 +111,7 @@ Let's see how we would go about wiring it up using an observer.
 First off, we need to create a simple +User+ scaffold:
 
 <shell>
-$ script/generate scaffold user name:string email:string login:string
+$ rails generate scaffold user name:string email:string login:string
 $ rake db:migrate
 </shell>
 
@@ -333,7 +333,7 @@ Receiving and parsing emails with Action Mailer can be a rather complex endeavou
 
 * Implement a +receive+ method in your mailer.
 
-* Configure your email server to forward emails from the address(es) you would like your app to receive to +/path/to/app/script/runner 'UserMailer.receive(STDIN.read)'+.
+* Configure your email server to forward emails from the address(es) you would like your app to receive to +/path/to/app/script/rails runner 'UserMailer.receive(STDIN.read)'+.
 
 Once a method called +receive+ is defined in any mailer, Action Mailer will parse the raw incoming email into an email object, decode it, instantiate a new mailer, and pass the email object to the mailer +receive+ instance method. Here's an example:
 
diff --git a/railties/guides/source/active_support_core_extensions.textile b/railties/guides/source/active_support_core_extensions.textile
index 3073c3a7a5..bf39ed4c9f 100644
--- a/railties/guides/source/active_support_core_extensions.textile
+++ b/railties/guides/source/active_support_core_extensions.textile
@@ -1805,7 +1805,7 @@ Rails hijacks +LoadError.new+ to return a +MissingSourceFile+ exception:
 $ ruby -e 'require "nonexistent"'
 ...: no such file to load -- nonexistent (LoadError)
 ...
-$ script/runner 'require "nonexistent"'
+$ rails runner 'require "nonexistent"'
 ...: no such file to load -- nonexistent (MissingSourceFile)
 ...
 </shell>
diff --git a/railties/guides/source/activerecord_validations_callbacks.textile b/railties/guides/source/activerecord_validations_callbacks.textile
index 9d0ee29ff2..dc61021f76 100644
--- a/railties/guides/source/activerecord_validations_callbacks.textile
+++ b/railties/guides/source/activerecord_validations_callbacks.textile
@@ -44,7 +44,7 @@ class Person < ActiveRecord::Base
 end
 </ruby>
 
-We can see how it works by looking at some script/console output:
+We can see how it works by looking at some +rails console+ output:
 
 <shell>
 >> p = Person.new(:name => "John Doe")
diff --git a/railties/guides/source/command_line.textile b/railties/guides/source/command_line.textile
index 1a571358a1..a84e928731 100644
--- a/railties/guides/source/command_line.textile
+++ b/railties/guides/source/command_line.textile
@@ -58,7 +58,7 @@ Without any prodding of any kind, +server+ will run our new shiny Rails app:
 
 <shell>
 $ cd commandsapp
-$ ./script/server
+$ rails server
 => Booting WEBrick...
 => Rails 2.2.0 application started on http://0.0.0.0:3000
 => Ctrl-C to shutdown server; call with --help for options
@@ -76,8 +76,8 @@ h4. +generate+
 The +generate+ command uses templates to create a whole lot of things. You can always find out what's available by running +generate+ by itself. Let's do that:
 
 <shell>
-$ ./script/generate
-Usage: ./script/generate generator [options] [args]
+$ rails generate
+Usage: rails generate generator [options] [args]
 
 ...
 ...
@@ -95,17 +95,17 @@ Using generators will save you a large amount of time by writing *boilerplate co
 
 Let's make our own controller with the controller generator. But what command should we use? Let's ask the generator:
 
-INFO: All Rails console utilities have help text. As with most *NIX utilities, you can try adding +--help+ or +-h+ to the end, for example +./script/server --help+.
+INFO: All Rails console utilities have help text. As with most *NIX utilities, you can try adding +--help+ or +-h+ to the end, for example +rails server --help+.
 
 <shell>
-$ ./script/generate controller
-Usage: ./script/generate controller ControllerName [options]
+$ rails generate controller
+Usage: rails generate controller ControllerName [options]
 
 ...
 ...
 
 Example:
-    ./script/generate controller CreditCard open debit credit close
+    rails generate controller CreditCard open debit credit close
 
     Credit card controller with URLs like /credit_card/debit.
         Controller: app/controllers/credit_card_controller.rb
@@ -114,7 +114,7 @@ Example:
         Test:       test/functional/credit_card_controller_test.rb
 
 Modules Example:
-    ./script/generate controller 'admin/credit_card' suspend late_fee
+    rails generate controller 'admin/credit_card' suspend late_fee
 
     Credit card admin controller with URLs /admin/credit_card/suspend.
         Controller: app/controllers/admin/credit_card_controller.rb
@@ -126,7 +126,7 @@ Modules Example:
 Ah, the controller generator is expecting parameters in the form of +generate controller ControllerName action1 action2+. Let's make a +Greetings+ controller with an action of *hello*, which will say something nice to us.
 
 <shell>
-$ ./script/generate controller Greetings hello
+$ rails generate controller Greetings hello
      exists  app/controllers/
      exists  app/helpers/
      create  app/views/greetings
@@ -157,10 +157,10 @@ Then the view, to display our nice message (in +app/views/greetings/hello.html.e
 <p><%= @message %></p>
 </html>
 
-Deal. Go check it out in your browser. Fire up your server. Remember? +./script/server+ at the root of your Rails application should do it.
+Deal. Go check it out in your browser. Fire up your server. Remember? +rails server+ at the root of your Rails application should do it.
 
 <shell>
-$ ./script/server
+$ rails server
 => Booting WEBrick...
 </shell>
 
@@ -173,13 +173,13 @@ INFO: With a normal, plain-old Rails application, your URLs will generally follo
 "What about data, though?", you ask over a cup of coffee. Rails comes with a generator for data models too. Can you guess its generator name?
 
 <shell>
-$ ./script/generate model
-Usage: ./script/generate model ModelName [field:type, field:type]
+$ rails generate model
+Usage: rails generate model ModelName [field:type, field:type]
 
 ...
 
 Examples:
-    ./script/generate model account
+    rails generate model account
 
         creates an Account model, test, fixture, and migration:
             Model:      app/models/account.rb
@@ -187,7 +187,7 @@ Examples:
             Fixtures:   test/fixtures/accounts.yml
             Migration:  db/migrate/XXX_add_accounts.rb
 
-    ./script/generate model post title:string body:text published:boolean
+    rails generate model post title:string body:text published:boolean
 
         creates a Post model with a string title, text body, and published flag.
 </shell>
@@ -197,7 +197,7 @@ But instead of generating a model directly (which we'll be doing later), let's s
 Let's set up a simple resource called "HighScore" that will keep track of our highest score on video games we play.
 
 <shell>
-$ ./script/generate scaffold HighScore game:string score:integer
+$ rails generate scaffold HighScore game:string score:integer
     exists  app/models/
     exists  app/controllers/
     exists  app/helpers/
@@ -244,13 +244,13 @@ $ rake db:migrate
 
 INFO: Let's talk about unit tests. Unit tests are code that tests and makes assertions about code. In unit testing, we take a little part of code, say a method of a model, and test its inputs and outputs. Unit tests are your friend. The sooner you make peace with the fact that your quality of life will drastically increase when you unit test your code, the better. Seriously. We'll make one in a moment.
 
-Let's see the interface Rails created for us. ./script/server; http://localhost:3000/high_scores
+Let's see the interface Rails created for us. rails server; http://localhost:3000/high_scores
 
 We can create new high scores (55,160 on Space Invaders!)
 
 h4. +console+
 
-The +console+ command lets you interact with your Rails application from the command line. On the underside, +script/console+ uses IRB, so if you've ever used it, you'll be right at home. This is useful for testing out quick ideas with code and changing data server-side without touching the website.
+The +console+ command lets you interact with your Rails application from the command line. On the underside, +rails console+ uses IRB, so if you've ever used it, you'll be right at home. This is useful for testing out quick ideas with code and changing data server-side without touching the website.
 
 h4. +dbconsole+
 
@@ -265,7 +265,7 @@ Let's say you're creating a website for a client who wants a small accounting sy
 There is such a thing! The plugin we're installing is called "acts_as_paranoid", and it lets models implement a "deleted_at" column that gets set when you call destroy. Later, when calling find, the plugin will tack on a database check to filter out "deleted" things.
 
 <shell>
-$ ./script/plugin install http://svn.techno-weenie.net/projects/plugins/acts_as_paranoid
+$ rails plugin install http://svn.techno-weenie.net/projects/plugins/acts_as_paranoid
 + ./CHANGELOG
 + ./MIT-LICENSE
 ...
@@ -277,7 +277,7 @@ h4. +runner+
 <tt>runner</tt> runs Ruby code in the context of Rails non-interactively. For instance:
 
 <shell>
-$ ./script/runner "Model.long_running_method"
+$ rails runner "Model.long_running_method"
 </shell>
 
 h4. +destroy+
@@ -285,7 +285,7 @@ h4. +destroy+
 Think of +destroy+ as the opposite of +generate+. It'll figure out what generate did, and undo it. Believe you-me, the creation of this tutorial used this command many times!
 
 <shell>
-$ ./script/generate model Oops
+$ rails generate model Oops
       exists  app/models/
       exists  test/unit/
       exists  test/fixtures/
@@ -294,7 +294,7 @@ $ ./script/generate model Oops
       create  test/fixtures/oops.yml
       exists  db/migrate
       create  db/migrate/20081221040817_create_oops.rb
-$ ./script/destroy model Oops
+$ rails destroy model Oops
     notempty  db/migrate
     notempty  db
           rm  db/migrate/20081221040817_create_oops.rb
@@ -314,7 +314,7 @@ h4. +about+
 Check it: Version numbers for Ruby, RubyGems, Rails, the Rails subcomponents, your application's folder, the current Rails environment name, your app's database adapter, and schema version! +about+ is useful when you need to ask for help, check if a security patch might affect you, or when you need some stats for an existing Rails installation.
 
 <shell>
-$ ./script/about
+$ rails about
 About your application's environment
 Ruby version              1.8.6 (i486-linux)
 RubyGems version          1.3.1
@@ -399,7 +399,7 @@ Many people have created a large number different web servers in Ruby, and many
 
 NOTE: For more details on the Rack integration, see "Rails on Rack":rails_on_rack.html.
 
-To use a different server, just install its gem, then use its name for the first parameter to +script/server+:
+To use a different server, just install its gem, then use its name for the first parameter to +rails server+:
 
 <shell>
 $ sudo gem install mongrel
@@ -412,9 +412,9 @@ Successfully installed mongrel-1.1.5
 ...
 ...
 Installing RDoc documentation for mongrel-1.1.5...
-$ script/server mongrel
-=> Booting Mongrel (use 'script/server webrick' to force WEBrick)
-=> Rails 2.2.0 application starting on http://0.0.0.0:3000
+$ rails server mongrel
+=> Booting Mongrel (use 'rails server webrick' to force WEBrick)
+=> Rails 3.0.0 application starting on http://0.0.0.0:3000
 ...
 </shell>
 
@@ -481,7 +481,7 @@ I got assigned some args:
 Then we'll make sure it got included in the list of available generators:
 
 <shell>
-$ ./script/generate
+$ rails generate
 ...
 ...
 Installed Generators
@@ -491,7 +491,7 @@ Installed Generators
 SWEET! Now let's generate some text, yeah!
 
 <shell>
-$ ./script/generate tutorial_test arg1 arg2 arg3
+$ rails generate tutorial_test arg1 arg2 arg3
       exists  public
       create  public/tutorial.txt
 </shell>
diff --git a/railties/guides/source/debugging_rails_applications.textile b/railties/guides/source/debugging_rails_applications.textile
index 94411a560e..cd0098d686 100644
--- a/railties/guides/source/debugging_rails_applications.textile
+++ b/railties/guides/source/debugging_rails_applications.textile
@@ -247,9 +247,9 @@ If you see the message in the console or logs:
 Make sure you have started your web server with the option +--debugger+:
 
 <shell>
-~/PathTo/rails_project$ script/server --debugger
-=> Booting Mongrel (use 'script/server webrick' to force WEBrick)
-=> Rails 2.2.0 application starting on http://0.0.0.0:3000
+~/PathTo/rails_project$ rails server --debugger
+=> Booting Mongrel (use 'rails server webrick' to force WEBrick)
+=> Rails 3.0.0 application starting on http://0.0.0.0:3000
 => Debugger enabled
 ...
 </shell>
@@ -472,10 +472,10 @@ class Author < ActiveRecord::Base
 end
 </ruby>
 
-TIP: You can use ruby-debug while using script/console. Just remember to +require "ruby-debug"+ before calling the +debugger+ method.
+TIP: You can use ruby-debug while using +rails console+. Just remember to +require "ruby-debug"+ before calling the +debugger+ method.
 
 <shell>
-/PathTo/project $ script/console
+/PathTo/project $ rails console
 Loading development environment (Rails 2.1.0)
 >> require "ruby-debug"
 => []
@@ -636,7 +636,7 @@ require 'bleak_house' if ENV['BLEAK_HOUSE']
 Start a server instance with BleakHouse integration:
 
 <shell>
-RAILS_ENV=production BLEAK_HOUSE=1 ruby-bleak-house ./script/server
+RAILS_ENV=production BLEAK_HOUSE=1 ruby-bleak-house rails server
 </shell>
 
 Make sure to run a couple hundred requests to get better data samples, then press +CTRL-C+. The server will stop and Bleak House will produce a dumpfile in +/tmp+:
diff --git a/railties/guides/source/generators.textile b/railties/guides/source/generators.textile
index fcd91f8956..4387fe3bd5 100644
--- a/railties/guides/source/generators.textile
+++ b/railties/guides/source/generators.textile
@@ -17,18 +17,18 @@ NOTE: This guide is about Rails generators for versions >= 3.0. Rails generators
 
 h3. First contact
 
-When you create an application using the +rails+ command, you are in fact using a Rails generator. After that, you can get a list of all available generators by just invoking +script/generate+:
+When you create an application using the +rails+ command, you are in fact using a Rails generator. After that, you can get a list of all available generators by just invoking +rails generate+:
 
 <shell>
 $ rails myapp
 $ cd myapp
-$ ruby script/generate
+$ rails generate
 </shell>
 
 You will get a list of all generators that comes with Rails. If you need a detailed description, for instance about the helper generator, you can simply do:
 
 <shell>
-$ ruby script/generate helper --help
+$ rails generate helper --help
 </shell>
 
 h3. Creating your first generator
@@ -50,13 +50,13 @@ Our new generator is quite simple: it inherits from +Rails::Generators::Base+ an
 To invoke our new generator, we just need to do:
 
 <shell>
-$ ruby script/generate initializer
+$ rails generate initializer
 </shell>
 
 Before we go on, let's see our brand new generator description:
 
 <shell>
-$ ruby script/generate initializer --help
+$ rails generate initializer --help
 </shell>
 
 Rails usually is able to generate good descriptions if a generator is namespaced, as +ActiveRecord::Generators::ModelGenerator+, but not in this particular case. We can solve this problem in two ways. The first one is calling +desc+ inside our generator:
@@ -77,7 +77,7 @@ h3. Creating generators with generators
 A faster way to create a generator is using the generator's generator:
 
 <shell>
-$ ruby script/generate generator initializer
+$ rails generate generator initializer
       create  lib/generators/initializer
       create  lib/generators/initializer/initializer_generator.rb
       create  lib/generators/initializer/USAGE
@@ -99,9 +99,9 @@ At first, we can notice that we are inheriting from +Rails::Generators::NamedBas
 We can see that by invoking the description of this new generator (don't forget to delete the old generator file):
 
 <shell>
-$ ruby script/generate initializer --help
+$ rails generate initializer --help
 Usage:
-  script/generate initializer NAME [options]
+  rails generate initializer NAME [options]
 </shell>
 
 We can also see in our new generator that it has a class method called +source_root+. This method points to where our generator templates will be placed and by default it points to the created directory under +RAILS_APP/lib/generators/initializer/templates+. In order to understand what a generator template means, let's create a file at +RAILS_APP/lib/generators/initializer/templates/initializer.rb+ with the following content:
@@ -128,7 +128,7 @@ end
 And let's execute our generator:
 
 <shell>
-$ ruby script/generate initializer foo
+$ rails generate initializer foo
 </shell>
 
 We can see that now a initializer named foo was created at +config/initializers/foo.rb+ with the contents of our template. That means that copy_file copied a file in our source root to the destination path we gave. The method +file_name+ is automatically created when we inherit from +Rails::Generators::NamedBase+.
@@ -166,7 +166,7 @@ end
 Before we customize our workflow, let's first see how our scaffold looks like:
 
 <shell>
-$ ruby script/generate scaffold User name:string
+$ rails generate scaffold User name:string
       invoke  active_record
       create    db/migrate/20091120125558_create_users.rb
       create    app/models/user.rb
@@ -212,7 +212,7 @@ If we generate another resource on scaffold, we can notice that neither styleshe
 To show that, we are going to create a new helper generator that simply adds some instance variable readers. First, we create a generator:
 
 <shell>
-$ ruby script/generate generator my_helper
+$ rails generate generator my_helper
 </shell>
 
 After that, we can delete both templates directory and the +source_root+ class method from our new generators, because we are not going to need them. So our new generator looks like the following:
@@ -232,7 +232,7 @@ end
 We can try out our new generator by creating a helper for users:
 
 <shell>
-$ ruby script/generate my_helper users
+$ rails generate my_helper users
 </shell>
 
 And it will generate the following helper file in app/helpers:
@@ -258,7 +258,7 @@ end
 And see it in action when invoking generator once again:
 
 <shell>
-$ ruby script/generate scaffold Post body:text
+$ rails generate scaffold Post body:text
       [...]
       invoke    my_helper
       create      app/helpers/posts_helper.rb
@@ -343,7 +343,7 @@ Rails::Generators.fallbacks[:shoulda] = :test_unit
 Now, if create a Comment scaffold, you will see that shoulda generators are being invoked, and at the end, they are just falling back to test unit generators:
 
 <shell>
-$ ruby script/generate scaffold Comment body:text
+$ rails generate scaffold Comment body:text
       invoke  active_record
       create    db/migrate/20091120151323_create_comments.rb
       create    app/models/comment.rb
diff --git a/railties/guides/source/getting_started.textile b/railties/guides/source/getting_started.textile
index bd6dbda199..a6ac7f0f5b 100644
--- a/railties/guides/source/getting_started.textile
+++ b/railties/guides/source/getting_started.textile
@@ -258,10 +258,10 @@ h3. Hello, Rails!
 One of the traditional places to start with a new language is by getting some text up on screen quickly. To do that in Rails, you need to create at minimum a controller and a view. Fortunately, you can do that in a single command. Enter this command in your terminal:
 
 <shell>
-$ script/generate controller home index
+$ rails generate controller home index
 </shell>
 
-TIP: If you're on Windows, or your Ruby is set up in some non-standard fashion, you may need to explicitly pass Rails +script+ commands to Ruby: +ruby script/generate controller home index+.
+TIP: If you're on Windows, or your Ruby is set up in some non-standard fashion, you may need to explicitly pass Rails +script+ commands to Ruby: +rails generate controller home index+.
 
 Rails will create several files for you, including +app/views/home/index.html.erb+. This is the template that will be used to display the results of the +index+ action (method) in the +home+ controller. Open this file in your text editor and edit it to contain a single line of code:
 
@@ -274,7 +274,7 @@ h4. Starting up the Web Server
 You actually have a functional Rails application already - after running only two commands! To see it, you need to start a web server on your development machine. You can do this by running another command:
 
 <shell>
-$ script/server
+$ rails server
 </shell>
 
 This will fire up an instance of the Mongrel web server by default (Rails can also use several other web servers). To see your application in action, open a browser window and navigate to +http://localhost:3000+. You should see Rails' default information page:
@@ -323,7 +323,7 @@ h3. Creating a Resource
 In the case of the blog application, you can start by generating a scaffolded Post resource: this will represent a single blog posting. To do this, enter this command in your terminal:
 
 <shell>
-$ script/generate scaffold Post name:string title:string content:text
+$ rails generate scaffold Post name:string title:string content:text
 </shell>
 
 NOTE. While scaffolding will get you up and running quickly, the "one size fits all" code that it generates is unlikely to be a perfect fit for your application. In most cases, you'll need to customize the generated code. Many experienced Rails developers avoid scaffolding entirely, preferring to write all or most of their source code from scratch.
@@ -349,7 +349,7 @@ The scaffold generator will build 14 files in your application, along with some
 
 h4. Running a Migration
 
-One of the products of the +script/generate scaffold+ command is a _database migration_. Migrations are Ruby classes that are designed to make it simple to create and modify database tables. Rails uses rake commands to run migrations, and it's possible to undo a migration after it's been applied to your database. Migration filenames include a timestamp to ensure that they're processed in the order that they were created.
+One of the products of the +rails generate scaffold+ command is a _database migration_. Migrations are Ruby classes that are designed to make it simple to create and modify database tables. Rails uses rake commands to run migrations, and it's possible to undo a migration after it's been applied to your database. Migration filenames include a timestamp to ensure that they're processed in the order that they were created.
 
 If you look in the +db/migrate/20090113124235_create_posts.rb+ file (remember, yours will have a slightly different name), here's what you'll find:
 
@@ -400,7 +400,7 @@ Now you're ready to start working with posts. To do that, navigate to +http://lo
 
 !images/posts_index.png(Posts Index screenshot)!
 
-This is the result of Rails rendering the +index+ view of your posts. There aren't currently any posts in the database, but if you click the +New Post+ link you can create one. After that, you'll find that you can edit posts, look at their details, or destroy them. All of the logic and HTML to handle this was built by the single +script/generate scaffold+ command.
+This is the result of Rails rendering the +index+ view of your posts. There aren't currently any posts in the database, but if you click the +New Post+ link you can create one. After that, you'll find that you can edit posts, look at their details, or destroy them. All of the logic and HTML to handle this was built by the single +rails generate scaffold+ command.
 
 TIP: In development mode (which is what you're working in by default), Rails reloads your application with every browser request, so there's no need to stop and restart the web server.
 
@@ -435,7 +435,7 @@ h4. Using the Console
 To see your validations in action, you can use the console. The console is a command-line tool that lets you execute Ruby code in the context of your application:
 
 <shell>
-$ script/console
+$ rails console
 </shell>
 
 After the console loads, you can use it to work with your application's models:
@@ -516,7 +516,7 @@ TIP: For more details on the rendering process, see "Layouts and Rendering in Ra
 
 h4. Customizing the Layout
 
-The view is only part of the story of how HTML is displayed in your web browser. Rails also has the concept of +layouts+, which are containers for views. When Rails renders a view to the browser, it does so by putting the view's HTML into a layout's HTML. The +script/generate scaffold+ command automatically created a default layout, +app/views/layouts/posts.html.erb+, for the posts. Open this layout in your editor and modify the +body+ tag:
+The view is only part of the story of how HTML is displayed in your web browser. Rails also has the concept of +layouts+, which are containers for views. When Rails renders a view to the browser, it does so by putting the view's HTML into a layout's HTML. The +rails generate scaffold+ command automatically created a default layout, +app/views/layouts/posts.html.erb+, for the posts. Open this layout in your editor and modify the +body+ tag:
 
 <erb>
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
@@ -859,7 +859,7 @@ h4. Generating a Model
 Models in Rails use a singular name, and their corresponding database tables use a plural name. For the model to hold comments, the convention is to use the name Comment. Even if you don't want to use the entire apparatus set up by scaffolding, most Rails developers still use generators to make things like models and controllers. To create the new model, run this command in your terminal:
 
 <shell>
-$ script/generate model Comment commenter:string body:text
+$ rails generate model Comment commenter:string body:text
     post:references
 </shell>
 
@@ -953,7 +953,7 @@ h4. Generating a Controller
 With the model in hand, you can turn your attention to creating a matching controller. Again, there's a generator for this:
 
 <shell>
-$ script/generate controller Comments index show new edit
+$ rails generate controller Comments index show new edit
 </shell>
 
 This creates eight files:
@@ -967,7 +967,7 @@ This creates eight files:
 * +test/functional/comments_controller_test.rb+ - The functional tests for the controller
 * +test/unit/helpers/comments_helper_test.rb+ - The unit tests for the helper
 
-The controller will be generated with empty methods and views for each action that you specified in the call to +script/generate controller+:
+The controller will be generated with empty methods and views for each action that you specified in the call to +rails generate controller+:
 
 <ruby>
 class CommentsController < ApplicationController
@@ -1052,7 +1052,7 @@ This creates a new +Comment+ object _and_ sets up the +post_id+ field to have th
 
 h4. Building Views
 
-Because you skipped scaffolding, you'll need to build views for comments "by hand". Invoking +script/generate controller+ will give you skeleton views, but they'll be devoid of actual content. Here's a first pass at fleshing out the comment views.
+Because you skipped scaffolding, you'll need to build views for comments "by hand". Invoking +rails generate controller+ will give you skeleton views, but they'll be devoid of actual content. Here's a first pass at fleshing out the comment views.
 
 The +views/comments/index.html.erb+ view:
 
@@ -1214,7 +1214,7 @@ h3. Building a Multi-Model Form
 Comments and posts are edited on two separate forms - which makes sense, given the flow of this mini-application. But what if you want to edit more than one thing on a single form? Rails 2.3 offers new support for nested forms. Let's add support for giving each post multiple tags, right in the form where you create the post. First, create a new model to hold the tags:
 
 <shell>
-$ script/generate model tag name:string post:references
+$ rails generate model tag name:string post:references
 </shell>
 
 Run the migration to create the database table:
diff --git a/railties/guides/source/migrations.textile b/railties/guides/source/migrations.textile
index 771c3e2523..558cbb4771 100644
--- a/railties/guides/source/migrations.textile
+++ b/railties/guides/source/migrations.textile
@@ -105,7 +105,7 @@ h4. Creating a Model
 The model and scaffold generators will create migrations appropriate for adding a new model. This migration will already contain instructions for creating the relevant table. If you tell Rails what columns you want then statements for adding those will also be created. For example, running
 
 <shell>
-ruby script/generate model Product name:string description:text
+rails generate model Product name:string description:text
 </shell>
 
 will create a migration that looks like this
@@ -135,7 +135,7 @@ h4. Creating a Standalone Migration
 If you are creating migrations for other purposes (for example to add a column to an existing table) then you can use the migration generator:
 
 <shell>
-ruby script/generate migration AddPartNumberToProducts
+rails generate migration AddPartNumberToProducts
 </shell>
 
 This will create an empty but appropriately named migration:
@@ -153,7 +153,7 @@ end
 If the migration name is of the form "AddXXXToYYY" or "RemoveXXXFromYYY" and is followed by a list of column names and types then a migration containing the appropriate +add_column+ and +remove_column+ statements will be created.
 
 <shell>
-ruby script/generate migration AddPartNumberToProducts part_number:string
+rails generate migration AddPartNumberToProducts part_number:string
 </shell>
 
 will generate
@@ -173,7 +173,7 @@ end
 Similarly,
 
 <shell>
-ruby script/generate migration RemovePartNumberFromProducts part_number:string
+rails generate migration RemovePartNumberFromProducts part_number:string
 </shell>
 
 generates
@@ -193,7 +193,7 @@ end
 You are not limited to one magically generated column, for example
 
 <shell>
-ruby script/generate migration AddDetailsToProducts part_number:string price:decimal
+rails generate migration AddDetailsToProducts part_number:string price:decimal
 </shell>
 
 generates
diff --git a/railties/guides/source/performance_testing.textile b/railties/guides/source/performance_testing.textile
index f0dc9acbb8..5c760a5966 100644
--- a/railties/guides/source/performance_testing.textile
+++ b/railties/guides/source/performance_testing.textile
@@ -37,7 +37,7 @@ h4. Generating Performance Tests
 Rails provides a generator called +performance_test+ for creating new performance tests:
 
 <shell>
-script/generate performance_test homepage
+rails generate performance_test homepage
 </shell>
 
 This generates +homepage_test.rb+ in the +test/performance+ directory:
@@ -381,19 +381,19 @@ h4. +benchmarker+
 Usage:
 
 <shell>
-$ script/performance/benchmarker [times] 'Person.expensive_way' 'Person.another_expensive_way' ...
+$ rails benchmarker [times] 'Person.expensive_way' 'Person.another_expensive_way' ...
 </shell>
 
 Examples:
 
 <shell>
-$ script/performance/benchmarker 10 'Item.all' 'CouchItem.all'
+$ rails benchmarker 10 'Item.all' 'CouchItem.all'
 </shell>
 
 If the +[times]+ argument is omitted, supplied methods are run just once:
 
 <shell>
-$ script/performance/benchmarker 'Item.first' 'Item.last'
+$ rails benchmarker 'Item.first' 'Item.last'
 </shell>
 
 h4. +profiler+
@@ -403,19 +403,19 @@ h4. +profiler+
 Usage:
 
 <shell>
-$ script/performance/profiler 'Person.expensive_method(10)' [times] [flat|graph|graph_html]
+$ rails profiler 'Person.expensive_method(10)' [times] [flat|graph|graph_html]
 </shell>
 
 Examples:
 
 <shell>
-$ script/performance/profiler 'Item.all'
+$ rails profiler 'Item.all'
 </shell>
 
 This will profile +Item.all+ in +RubyProf::WALL_TIME+ measure mode. By default, it prints flat output to the shell.
 
 <shell>
-$ script/performance/profiler 'Item.all' 10 graph
+$ rails profiler 'Item.all' 10 graph
 </shell>
 
 This will profile +10.times { Item.all }+ with +RubyProf::WALL_TIME+ measure mode and print graph output to the shell.
@@ -423,7 +423,7 @@ This will profile +10.times { Item.all }+ with +RubyProf::WALL_TIME+ measure mod
 If you want to store the output in a file:
 
 <shell>
-$ script/performance/profiler 'Item.all' 10 graph 2> graph.txt
+$ rails profiler 'Item.all' 10 graph 2> graph.txt
 </shell>
 
 h3. Helper Methods
diff --git a/railties/guides/source/plugins.textile b/railties/guides/source/plugins.textile
index 06d0d493e4..71e1a7e3d3 100644
--- a/railties/guides/source/plugins.textile
+++ b/railties/guides/source/plugins.textile
@@ -39,9 +39,9 @@ The examples in this guide require that you have a working rails application.  T
 gem install rails
 rails yaffle_guide
 cd yaffle_guide
-script/generate scaffold bird name:string
+rails generate scaffold bird name:string
 rake db:migrate
-script/server
+rails server
 </pre>
 
 Then navigate to http://localhost:3000/birds.  Make sure you have a functioning rails app before continuing.
@@ -57,16 +57,16 @@ This creates a plugin in 'vendor/plugins' including an 'init.rb' and 'README' as
 
 Examples:
 <pre>
-./script/generate plugin yaffle
-./script/generate plugin yaffle --with-generator
+rails generate plugin yaffle
+rails generate plugin yaffle --with-generator
 </pre>
 
-To get more detailed help on the plugin generator, type +./script/generate plugin+.
+To get more detailed help on the plugin generator, type +rails generate plugin+.
 
 Later on this guide will describe how to work with generators, so go ahead and generate your plugin with the +--with-generator+ option now:
 
 <pre>
-./script/generate plugin yaffle --with-generator
+rails generate plugin yaffle --with-generator
 </pre>
 
 You should see the following output:
@@ -334,7 +334,7 @@ end
 To test that your method does what it says it does, run the unit tests with +rake+ from your plugin directory.  To see this in action, fire up a console and start squawking:
 
 <shell>
-$ ./script/console
+$ rails console
 >> "Hello World".to_squawk
 => "squawk! Hello World"
 </shell>
@@ -871,7 +871,7 @@ If you plan to distribute your plugin, developers will expect at least a minimum
 Rails ships with several built-in generators.  You can see all of the generators available to you by typing the following at the command line:
 
 <shell>
-./script/generate
+rails generate
 </shell>
 
 You should see something like this:
@@ -882,7 +882,7 @@ Installed Generators
   Builtin: controller, integration_test, mailer, migration, model, observer, plugin, resource, scaffold, session_migration
 </shell>
 
-When you run +script/generate yaffle_definition -h+ you should see the contents of your 'vendor/plugins/yaffle/generators/yaffle_definition/USAGE'.
+When you run +rails generate yaffle_definition -h+ you should see the contents of your 'vendor/plugins/yaffle/generators/yaffle_definition/USAGE'.
 
 For this plugin, update the USAGE file could look like this:
 
@@ -1111,11 +1111,11 @@ end
 To see this work, type:
 
 <shell>
-./script/generate yaffle_route
-./script/destroy yaffle_route
+rails generate yaffle_route
+rails destroy yaffle_route
 </shell>
 
-NOTE: If you haven't set up the custom route from above, 'script/destroy' will fail and you'll have to remove it manually.
+NOTE: If you haven't set up the custom route from above, 'rails destroy' will fail and you'll have to remove it manually.
 
 h3. Migrations
 
@@ -1195,7 +1195,7 @@ h4. Generate Migrations
 
 Generating migrations has several advantages over other methods.  Namely, you can allow other developers to more easily customize the migration.  The flow looks like this:
 
- * call your script/generate script and pass in whatever options they need
+ * call your rails generate script and pass in whatever options they need
  * examine the generated migration, adding/removing columns or other options as necessary
 
 This example will demonstrate how to use one of the built-in generator methods named 'migration_template' to create a migration file.  Extending the rails migration generator requires a somewhat intimate knowledge of the migration generator internals, so it's best to write a test first:
@@ -1289,7 +1289,7 @@ It's courteous to check to see if table names are being pluralized whenever you
 To run the generator, type the following at the command line:
 
 <shell>
-./script/generate yaffle_migration bird
+rails generate yaffle_migration bird
 </shell>
 
 and you will see a new file:
diff --git a/railties/guides/source/rails_on_rack.textile b/railties/guides/source/rails_on_rack.textile
index df93580e89..eef44d9ec9 100644
--- a/railties/guides/source/rails_on_rack.textile
+++ b/railties/guides/source/rails_on_rack.textile
@@ -30,11 +30,11 @@ h4. Rails Application's Rack Object
 
 <tt>ActionController::Dispatcher.new</tt> is the primary Rack application object of a Rails application. Any Rack compliant web server should be using +ActionController::Dispatcher.new+ object to serve a Rails application.</p>
 
-h4. +script/server+
+h4. +rails server+
 
-<tt>script/server</tt> does the basic job of creating a +Rack::Builder+ object and starting the webserver. This is Rails' equivalent of Rack's +rackup+ script.
+<tt>rails server</tt> does the basic job of creating a +Rack::Builder+ object and starting the webserver. This is Rails' equivalent of Rack's +rackup+ script.
 
-Here's how +script/server+ creates an instance of +Rack::Builder+
+Here's how +rails server+ creates an instance of +Rack::Builder+
 
 <ruby>
 app = Rack::Builder.new {
@@ -54,7 +54,7 @@ Middlewares used in the code above are primarily useful only in the development
 
 h4. +rackup+
 
-To use +rackup+ instead of Rails' +script/server+, you can put the following inside +config.ru+ of your Rails application's root directory:
+To use +rackup+ instead of Rails' +rails server+, you can put the following inside +config.ru+ of your Rails application's root directory:
 
 <ruby>
 # RAILS_ROOT/config.ru
@@ -233,7 +233,7 @@ h4. Generating a Metal Application
 Rails provides a generator called +metal+ for creating a new Metal application:
 
 <shell>
-$ script/generate metal poller
+$ rails generate metal poller
 </shell>
 
 This generates +poller.rb+ in the +app/metal+ directory:
diff --git a/railties/guides/source/testing.textile b/railties/guides/source/testing.textile
index c7b475899f..ac9fb4276e 100644
--- a/railties/guides/source/testing.textile
+++ b/railties/guides/source/testing.textile
@@ -56,7 +56,7 @@ h5. What are Fixtures?
 
 _Fixtures_ is a fancy word for sample data. Fixtures allow you to populate your testing database with predefined data before your tests run. Fixtures are database independent and assume one of two formats: *YAML* or *CSV*. In this guide we will use *YAML* which is the preferred format.
 
-You'll find fixtures under your +test/fixtures+ directory. When you run +script/generate model+ to create a new model, fixture stubs will be automatically created and placed in this directory.
+You'll find fixtures under your +test/fixtures+ directory. When you run +rails generate model+ to create a new model, fixture stubs will be automatically created and placed in this directory.
 
 h5. YAML
 
@@ -144,10 +144,10 @@ For this guide we will be using Rails _scaffolding_. It will create the model, a
 
 NOTE: For more information on Rails _scaffolding_, refer to "Getting Started with Rails":getting_started.html
 
-When you use +script/generate scaffold+, for a resource among other things it creates a test stub in the +test/unit+ folder:
+When you use +rails generate scaffold+, for a resource among other things it creates a test stub in the +test/unit+ folder:
 
 <pre>
-$ script/generate scaffold post title:string body:text
+$ rails generate scaffold post title:string body:text
 ...
 create  app/models/post.rb
 create  test/unit/post_test.rb
@@ -604,7 +604,7 @@ Integration tests are used to test the interaction among any number of controlle
 Unlike Unit and Functional tests, integration tests have to be explicitly created under the 'test/integration' folder within your application. Rails provides a generator to create an integration test skeleton for you.
 
 <shell>
-$ script/generate integration_test user_flows
+$ rails generate integration_test user_flows
       exists  test/integration/
       create  test/integration/user_flows_test.rb
 </shell>