Merge pull request #33229 from albertoalmagro/albertoalmagro/prefer-rails-command-over-bin-rails

Prefer rails command over bin/rails

1 files changed, 16 insertions, 16 deletions

diff --git a/guides/source/engines.md b/guides/source/engines.md
index e6634c78e3..1e93a19c84 100644
--- a/guides/source/engines.md
+++ b/guides/source/engines.md
@@ -202,7 +202,7 @@ within the `Engine` class definition. Without it, classes generated in an engine
 **may** conflict with an application.
 
 What this isolation of the namespace means is that a model generated by a call
-to `bin/rails g model`, such as `bin/rails g model article`, won't be called `Article`, but
+to `rails g model`, such as `rails g model article`, won't be called `Article`, but
 instead be namespaced and called `Blorgh::Article`. In addition, the table for the
 model is namespaced, becoming `blorgh_articles`, rather than simply `articles`.
 Similar to the model namespacing, a controller called `ArticlesController` becomes
@@ -322,7 +322,7 @@ The first thing to generate for a blog engine is the `Article` model and related
 controller. To quickly generate this, you can use the Rails scaffold generator.
 
 ```bash
-$ bin/rails generate scaffold article title:string text:text
+$ rails generate scaffold article title:string text:text
 ```
 
 This command will output this information:
@@ -430,7 +430,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 `bin/rails db:migrate` at the root
+You can see what the engine has so far by running `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
@@ -472,7 +472,7 @@ From the application root, run the model generator. Tell it to generate a
 and `text` text column.
 
 ```bash
-$ bin/rails generate model Comment article_id:integer text:text
+$ rails generate model Comment article_id:integer text:text
 ```
 
 This will output the following:
@@ -492,7 +492,7 @@ called `Blorgh::Comment`. Now run the migration to create our blorgh_comments
 table:
 
 ```bash
-$ bin/rails db:migrate
+$ rails db:migrate
 ```
 
 To show the comments on an article, edit `app/views/blorgh/articles/show.html.erb` and
@@ -566,7 +566,7 @@ The route now exists, but the controller that this route goes to does not. To
 create it, run this command from the application root:
 
 ```bash
-$ bin/rails g controller comments
+$ rails g controller comments
 ```
 
 This will generate the following things:
@@ -701,14 +701,14 @@ engine's models can query them correctly. To copy these migrations into the
 application run the following command from the application's root:
 
 ```bash
-$ bin/rails blorgh:install:migrations
+$ rails blorgh:install:migrations
 ```
 
 If you have multiple engines that need migrations copied over, use
 `railties:install:migrations` instead:
 
 ```bash
-$ bin/rails railties:install:migrations
+$ rails railties:install:migrations
 ```
 
 This command, when run for the first time, will copy over all the migrations
@@ -726,7 +726,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 `bin/rails
+To run these migrations within the context of the application, simply run `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
@@ -737,14 +737,14 @@ If you would like to run migrations only from one engine, you can do it by
 specifying `SCOPE`:
 
 ```bash
-bin/rails db:migrate SCOPE=blorgh
+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
-bin/rails db:migrate SCOPE=blorgh VERSION=0
+rails db:migrate SCOPE=blorgh VERSION=0
 ```
 
 ### Using a Class Provided by the Application
@@ -771,7 +771,7 @@ application:
 rails g model user name:string
 ```
 
-The `bin/rails db:migrate` command needs to be run here to ensure that our
+The `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
@@ -831,7 +831,7 @@ of associating the records in the `blorgh_articles` table with the records in th
 To generate this new column, run this command within the engine:
 
 ```bash
-$ bin/rails g migration add_author_id_to_blorgh_articles author_id:integer
+$ rails g migration add_author_id_to_blorgh_articles author_id:integer
 ```
 
 NOTE: Due to the migration's name and the column specification after it, Rails
@@ -843,7 +843,7 @@ This migration will need to be run on the application. To do that, it must first
 be copied using this command:
 
 ```bash
-$ bin/rails blorgh:install:migrations
+$ rails blorgh:install:migrations
 ```
 
 Notice that only _one_ migration was copied over here. This is because the first
@@ -858,7 +858,7 @@ Copied migration [timestamp]_add_author_id_to_blorgh_articles.blorgh.rb from blo
 Run the migration using:
 
 ```bash
-$ bin/rails db:migrate
+$ rails db:migrate
 ```
 
 Now with all the pieces in place, an action will take place that will associate
@@ -1365,7 +1365,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 `bin/rails assets:precompile` is triggered.
+your engine assets when `rails assets:precompile` is triggered.
 
 You can define assets for precompilation in `engine.rb`: