Merge pull request #23119 from Gaurav2728/update_guide_to_bin_rails_command

use bin/rails default instead of rake commands [ci skip]

6 files changed, 37 insertions, 37 deletions

diff --git a/guides/source/active_record_migrations.md b/guides/source/active_record_migrations.md
index a4a23395fb..83f4b951ee 100644
--- a/guides/source/active_record_migrations.md
+++ b/guides/source/active_record_migrations.md
@@ -12,7 +12,7 @@ After reading this guide, you will know:
 
 * The generators you can use to create them.
 * The methods Active Record provides to manipulate your database.
-* The Rake tasks that manipulate migrations and your schema.
+* The bin/rails tasks that manipulate migrations and your schema.
 * How migrations relate to `schema.rb`.
 
 --------------------------------------------------------------------------------
@@ -717,9 +717,9 @@ you will have to use `structure.sql` as dump method. See
 Running Migrations
 ------------------
 
-Rails provides a set of Rake tasks to run certain sets of migrations.
+Rails provides a set of bin/rails tasks to run certain sets of migrations.
 
-The very first migration related Rake task you will use will probably be
+The very first migration related bin/rails task you will use will probably be
 `rails db:migrate`. In its most basic form it just runs the `change` or `up`
 method for all the migrations that have not yet been run. If there are
 no such migrations, it exits. It will run these migrations in order based
@@ -772,7 +772,7 @@ if you need to go more than one version back, for example:
 $ bin/rails db:migrate:redo STEP=3
 ```
 
-Neither of these Rake tasks do anything you could not do with `db:migrate`. They
+Neither of these bin/rails tasks do anything you could not do with `db:migrate`. They
 are simply more convenient, since you do not need to explicitly specify the
 version to migrate to.
 
@@ -784,7 +784,7 @@ it with the seed data.
 ### Resetting the Database
 
 The `rails db:reset` task will drop the database and set it up again. This is
-functionally equivalent to `rake db:drop db:setup`.
+functionally equivalent to `rails db:drop db:setup`.
 
 NOTE: This is not the same as running all the migrations. It will only use the
 contents of the current `db/schema.rb` or `db/structure.sql` file. If a migration can't be rolled back,
@@ -809,7 +809,7 @@ Active Record believes that it has already been run.
 
 ### Running Migrations in Different Environments
 
-By default running `rake db:migrate` will run in the `development` environment.
+By default running `bin/rails db:migrate` will run in the `development` environment.
 To run migrations against another environment you can specify it using the
 `RAILS_ENV` environment variable while running the command. For example to run
 migrations against the `test` environment you could run:
@@ -886,7 +886,7 @@ Occasionally you will make a mistake when writing a migration. If you have
 already run the migration then you cannot just edit the migration and run the
 migration again: Rails thinks it has already run the migration and so will do
 nothing when you run `rails db:migrate`. You must rollback the migration (for
-example with `rake db:rollback`), edit your migration and then run
+example with `bin/rails db:rollback`), edit your migration and then run
 `rails db:migrate` to run the corrected version.
 
 In general, editing existing migrations is not a good idea. You will be
diff --git a/guides/source/engines.md b/guides/source/engines.md
index 8382bde4d3..697938434c 100644
--- a/guides/source/engines.md
+++ b/guides/source/engines.md
@@ -423,7 +423,7 @@ Finally, the assets for this resource are generated in two files:
 `app/assets/stylesheets/blorgh/articles.css`. You'll see how to use these a little
 later.
 
-You can see what the engine has so far by running `rake db:migrate` at the root
+You can see what the engine has so far by running `bin/rails db:migrate` at the root
 of our engine to run the migration generated by the scaffold generator, and then
 running `rails server` in `test/dummy`. When you open
 `http://localhost:3000/blorgh/articles` you will see the default scaffold that has
@@ -485,7 +485,7 @@ called `Blorgh::Comment`. Now run the migration to create our blorgh_comments
 table:
 
 ```bash
-$ rake db:migrate
+$ bin/rails db:migrate
 ```
 
 To show the comments on an article, edit `app/views/blorgh/articles/show.html.erb` and
@@ -694,14 +694,14 @@ engine's models can query them correctly. To copy these migrations into the
 application run the following command from the `test/dummy` directory of your Rails engine:
 
 ```bash
-$ rake blorgh:install:migrations
+$ bin/rails blorgh:install:migrations
 ```
 
 If you have multiple engines that need migrations copied over, use
 `railties:install:migrations` instead:
 
 ```bash
-$ rake railties:install:migrations
+$ bin/rails railties:install:migrations
 ```
 
 This command, when run for the first time, will copy over all the migrations
@@ -719,7 +719,7 @@ timestamp (`[timestamp_2]`) will be the current time plus a second. The reason
 for this is so that the migrations for the engine are run after any existing
 migrations in the application.
 
-To run these migrations within the context of the application, simply run `rake
+To run these migrations within the context of the application, simply run `bin/rails
 db:migrate`. When accessing the engine through `http://localhost:3000/blog`, the
 articles will be empty. This is because the table created inside the application is
 different from the one created within the engine. Go ahead, play around with the
@@ -730,14 +730,14 @@ If you would like to run migrations only from one engine, you can do it by
 specifying `SCOPE`:
 
 ```bash
-rake db:migrate SCOPE=blorgh
+bin/rails db:migrate SCOPE=blorgh
 ```
 
 This may be useful if you want to revert engine's migrations before removing it.
 To revert all migrations from blorgh engine you can run code such as:
 
 ```bash
-rake db:migrate SCOPE=blorgh VERSION=0
+bin/rails db:migrate SCOPE=blorgh VERSION=0
 ```
 
 ### Using a Class Provided by the Application
@@ -764,7 +764,7 @@ application:
 rails g model user name:string
 ```
 
-The `rake db:migrate` command needs to be run here to ensure that our
+The `bin/rails db:migrate` command needs to be run here to ensure that our
 application has the `users` table for future use.
 
 Also, to keep it simple, the articles form will have a new text field called
@@ -836,7 +836,7 @@ This migration will need to be run on the application. To do that, it must first
 be copied using this command:
 
 ```bash
-$ rake blorgh:install:migrations
+$ bin/rails blorgh:install:migrations
 ```
 
 Notice that only _one_ migration was copied over here. This is because the first
@@ -851,7 +851,7 @@ Copied migration [timestamp]_add_author_id_to_blorgh_articles.blorgh.rb from blo
 Run the migration using:
 
 ```bash
-$ rake db:migrate
+$ bin/rails db:migrate
 ```
 
 Now with all the pieces in place, an action will take place that will associate
@@ -1354,7 +1354,7 @@ need to require `admin.css` or `admin.js`. Only the gem's admin layout needs
 these assets. It doesn't make sense for the host app to include
 `"blorgh/admin.css"` in its stylesheets. In this situation, you should
 explicitly define these assets for precompilation.  This tells sprockets to add
-your engine assets when `rake assets:precompile` is triggered.
+your engine assets when `bin/rails assets:precompile` is triggered.
 
 You can define assets for precompilation in `engine.rb`:
 
diff --git a/guides/source/getting_started.md b/guides/source/getting_started.md
index 9f38de6247..857b5ced22 100644
--- a/guides/source/getting_started.md
+++ b/guides/source/getting_started.md
@@ -300,7 +300,7 @@ Rails.application.routes.draw do
 
   # The priority is based upon order of creation:
   # first created -> highest priority.
-  # See how all your routes lay out with "rake routes".
+  # See how all your routes lay out with "bin/rails routes".
   #
   # You can have the root of your site routed with "root"
   # root 'welcome#index'
@@ -359,13 +359,13 @@ Rails.application.routes.draw do
 end
 ```
 
-If you run `bin/rake routes`, you'll see that it has defined routes for all the
+If you run `bin/rails routes`, you'll see that it has defined routes for all the
 standard RESTful actions.  The meaning of the prefix column (and other columns)
 will be seen later, but for now notice that Rails has inferred the
 singular form `article` and makes meaningful use of the distinction.
 
 ```bash
-$ bin/rake routes
+$ bin/rails routes
       Prefix Verb   URI Pattern                  Controller#Action
     articles GET    /articles(.:format)          articles#index
              POST   /articles(.:format)          articles#create
@@ -559,10 +559,10 @@ this:
 
 In this example, the `articles_path` helper is passed to the `:url` option.
 To see what Rails will do with this, we look back at the output of
-`bin/rake routes`:
+`bin/rails routes`:
 
 ```bash
-$ bin/rake routes
+$ bin/rails routes
       Prefix Verb   URI Pattern                  Controller#Action
     articles GET    /articles(.:format)          articles#index
              POST   /articles(.:format)          articles#create
@@ -702,10 +702,10 @@ two timestamp fields to allow Rails to track article creation and update times.
 TIP: For more information about migrations, refer to [Rails Database Migrations]
 (migrations.html).
 
-At this point, you can use a rake command to run the migration:
+At this point, you can use a bin/rails command to run the migration:
 
 ```bash
-$ bin/rake db:migrate
+$ bin/rails db:migrate
 ```
 
 Rails will execute this migration command and tell you it created the Articles
@@ -722,7 +722,7 @@ NOTE. Because you're working in the development environment by default, this
 command will apply to the database defined in the `development` section of your
 `config/database.yml` file. If you would like to execute migrations in another
 environment, for instance in production, you must explicitly pass it when
-invoking the command: `bin/rake db:migrate RAILS_ENV=production`.
+invoking the command: `bin/rails db:migrate RAILS_ENV=production`.
 
 ### Saving data in the controller
 
@@ -809,7 +809,7 @@ If you submit the form again now, Rails will complain about not finding the
 `show` action. That's not very useful though, so let's add the `show` action
 before proceeding.
 
-As we have seen in the output of `bin/rake routes`, the route for `show` action is
+As we have seen in the output of `bin/rails routes`, the route for `show` action is
 as follows:
 
 ```
@@ -871,7 +871,7 @@ Visit <http://localhost:3000/articles/new> and give it a try!
 ### Listing all articles
 
 We still need a way to list all our articles, so let's do that.
-The route for this as per output of `bin/rake routes` is:
+The route for this as per output of `bin/rails routes` is:
 
 ```
 articles GET    /articles(.:format)          articles#index
@@ -1366,7 +1366,7 @@ Then do the same for the `app/views/articles/edit.html.erb` view:
 
 We're now ready to cover the "D" part of CRUD, deleting articles from the
 database. Following the REST convention, the route for
-deleting articles as per output of `bin/rake routes` is:
+deleting articles as per output of `bin/rails routes` is:
 
 ```ruby
 DELETE /articles/:id(.:format)      articles#destroy
@@ -1562,7 +1562,7 @@ for it, and a foreign key constraint that points to the `id` column of the `arti
 table. Go ahead and run the migration:
 
 ```bash
-$ bin/rake db:migrate
+$ bin/rails db:migrate
 ```
 
 Rails is smart enough to only execute the migrations that have not already been
diff --git a/guides/source/plugins.md b/guides/source/plugins.md
index 68e54f2414..8f055f8fe3 100644
--- a/guides/source/plugins.md
+++ b/guides/source/plugins.md
@@ -247,7 +247,7 @@ and migrating the database. First, run:
 
 ```bash
 $ cd test/dummy
-$ bin/rake db:migrate
+$ bin/rails db:migrate
 ```
 
 While you are here, change the Hickwall and Wickwall models so that they know that they are supposed to act
diff --git a/guides/source/routing.md b/guides/source/routing.md
index 9401132500..09491f3c9a 100644
--- a/guides/source/routing.md
+++ b/guides/source/routing.md
@@ -1116,7 +1116,7 @@ Rails offers facilities for inspecting and testing your routes.
 
 ### Listing Existing Routes
 
-To get a complete list of the available routes in your application, visit `http://localhost:3000/rails/info/routes` in your browser while your server is running in the **development** environment. You can also execute the `rake routes` command in your terminal to produce the same output.
+To get a complete list of the available routes in your application, visit `http://localhost:3000/rails/info/routes` in your browser while your server is running in the **development** environment. You can also execute the `rails routes` command in your terminal to produce the same output.
 
 Both methods will list all of your routes, in the same order that they appear in `config/routes.rb`. For each route, you'll see:
 
@@ -1125,7 +1125,7 @@ Both methods will list all of your routes, in the same order that they appear in
 * The URL pattern to match
 * The routing parameters for the route
 
-For example, here's a small section of the `rake routes` output for a RESTful route:
+For example, here's a small section of the `rails routes` output for a RESTful route:
 
 ```
     users GET    /users(.:format)          users#index
@@ -1137,10 +1137,10 @@ edit_user GET    /users/:id/edit(.:format) users#edit
 You may restrict the listing to the routes that map to a particular controller setting the `CONTROLLER` environment variable:
 
 ```bash
-$ CONTROLLER=users bin/rake routes
+$ CONTROLLER=users bin/rails routes
 ```
 
-TIP: You'll find that the output from `rake routes` is much more readable if you widen your terminal window until the output lines don't wrap.
+TIP: You'll find that the output from `rails routes` is much more readable if you widen your terminal window until the output lines don't wrap.
 
 ### Testing Routes
 
diff --git a/guides/source/testing.md b/guides/source/testing.md
index 84f80e3c37..bb6d322357 100644
--- a/guides/source/testing.md
+++ b/guides/source/testing.md
@@ -399,11 +399,11 @@ structure. The test helper checks whether your test database has any pending
 migrations. If so, it will try to load your `db/schema.rb` or `db/structure.sql`
 into the test database. If migrations are still pending, an error will be
 raised. Usually this indicates that your schema is not fully migrated. Running
-the migrations against the development database (`bin/rake db:migrate`) will
+the migrations against the development database (`bin/rails db:migrate`) will
 bring the schema up to date.
 
 NOTE: If existing migrations required modifications, the test database needs to
-be rebuilt. This can be done by executing `bin/rake db:test:prepare`.
+be rebuilt. This can be done by executing `bin/rails db:test:prepare`.
 
 ### The Low-Down on Fixtures