docs: Remove $ sign in code examples

docs/01-get-started/01-creating-endpoints.md

@@ -38,8 +38,8 @@ development:
 Next, we add the Dartantic AI package as a dependency to our server. This package provides a convenient interface for working with different AI providers, including Google's Gemini API.
 
 ```bash
-$ cd magic_recipe_server
-$ dart pub add dartantic_ai
+cd magic_recipe_server
+dart pub add dartantic_ai
 ```
 
 ## Create a new endpoint
@@ -100,8 +100,8 @@ For methods to be recognized by Serverpod, they need to return a typed `Future`
 Now, you need to generate the code for your new endpoint. You do this by running `serverpod generate` in the server directory of your project:
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 `serverpod generate` will create bindings for the endpoint and register them in the server's `generated/protocol.dart` file. It will also generate the required client code so that you can call your new `generateRecipe` method from your app.
@@ -221,16 +221,16 @@ Before you start your server, ensure no other Serverpod server is running. Also,
 Let's try our new recipe app! First, start the server:
 
 ```bash
-$ cd magic_recipe_server
-$ docker compose up -d
-$ dart bin/main.dart --apply-migrations
+cd magic_recipe_server
+docker compose up -d
+dart bin/main.dart --apply-migrations
 ```
 
 Now, you can start the Flutter app:
 
 ```bash
-$ cd magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser:

docs/01-get-started/02-models-and-data.md

@@ -34,8 +34,8 @@ You can use most primitive Dart types here or any other models you have specifie
 To generate the code for the model, run the `serverpod generate` command in your server directory:
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 This will generate the code for the model and create a new file called `recipe.dart` in the `lib/src/generated` directory. It will also update the client code in `magic_recipe/magic_recipe_client` so you can use it in your Flutter app.
@@ -133,8 +133,8 @@ class RecipeEndpoint extends Endpoint {
 First, we need to update our generated client by running `serverpod generate`.
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 Now that we have created the `Recipe` model we can use it in the app. We will do this in the `_callGenerateRecipe` method of the `magic_recipe_flutter/lib/main.dart` file. Let's update our `RecipeWidget` so that it displays the author and year of the recipe in addition to the recipe itself.
@@ -433,16 +433,16 @@ class ResultDisplay extends StatelessWidget {
 First, start the server:
 
 ```bash
-$ cd magic_recipe_server
-$ docker compose up -d
-$ dart bin/main.dart
+cd magic_recipe_server
+docker compose up -d
+dart bin/main.dart
 ```
 
 Then, start the Flutter app:
 
 ```bash
-$ cd magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser. It should look something like this:

docs/01-get-started/03-working-with-the-database.md

@@ -42,9 +42,9 @@ To create a migration, follow these two steps in order:
 2. Run `serverpod create-migration` to create the necessary database migration.
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
-$ serverpod create-migration
+cd magic_recipe_server
+serverpod generate
+serverpod create-migration
 ```
 
 Each time you run `serverpod create-migration`, a new migration file will be created in your _migrations_ folder. These step-by-step migrations provide a history of your database changes and allow you to roll back changes if needed.
@@ -190,8 +190,8 @@ The `insertRow` method is used to insert a new row into the database. The `find`
 Like before, when you change something that has an effect on your client code, you need to run `serverpod generate`. We don't need to run `serverpod create-migrations` again because we already created a migration in the previous step and haven't done any changes that affect the database.
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 ## Call the endpoint from the app
@@ -434,9 +434,9 @@ To run the application with database support, follow these steps in order:
 First, start the database and apply migrations:
 
 ```bash
-$ cd magic_recipe_server
-$ docker compose up -d                   # Start the database container
-$ dart bin/main.dart --apply-migrations  # Apply any pending migrations
+cd magic_recipe_server
+docker compose up -d                   # Start the database container
+dart bin/main.dart --apply-migrations  # Apply any pending migrations
 ```
 
 :::tip
@@ -446,8 +446,8 @@ The `--apply-migrations` flag is safe to use during development - if no migratio
 Next, launch the Flutter app:
 
 ```bash
-$ cd magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe_flutter
+flutter run -d chrome
 ```
 
 ## Summary

docs/06-concepts/06-database/01-connection.md

@@ -100,19 +100,19 @@ development:
 A newly created Serverpod project has a preconfigured Docker instance with a Postgres database set up. Run the following command from the root of the `server` package to start the database:
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 To stop the database run:
 
 ```bash
-$ docker compose stop
+docker compose stop
 ```
 
 To remove the database and __delete__ all associated data, run:
 
 ```bash
-$ docker compose down -v
+docker compose down -v
 ```
 
 ## Connecting to a custom Postgres instance

docs/06-concepts/06-database/11-migrations.md

@@ -28,7 +28,7 @@ If you want to transition a manually managed table to then be managed by Serverp
 To create a migration navigate to your project's `server` package directory and run the `create-migration` command.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 The command reads the database schema from the last migration, then compares it to the database schema necessary to accommodate the projects, and any module dependencies, current database requirements. If differences are identified, a new migration is created in the `migrations` directory to roll the database forward.
@@ -47,15 +47,15 @@ The migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 ### Tag migration
 
 Tags can be useful to identify migrations that introduced specific changes to the project. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-migration --tag "v1-0-0"
+serverpod create-migration --tag "v1-0-0"
 ```
 
 This would create a migration named `<timestamp>-v1-0-0`:
@@ -97,13 +97,13 @@ For each migration, five files are created:
 Migrations are applied using the server runtime. To apply migrations, navigate to your project's `server` package directory, then start the server with the `--apply-migrations` flag. Migrations are applied as part of the startup sequence and the framework asserts that each migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-migrations
+dart run bin/main.dart --apply-migrations
 ```
 
 Migrations can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 This is useful if migrations are applied as part of an automated process.
@@ -119,7 +119,7 @@ By default, the command connects to and pulls a live database schema from a runn
 To create a repair migration, navigate to your project's `server` package directory and run the `create-repair-migration` command.
 
 ```bash
-$ serverpod create-repair-migration
+serverpod create-repair-migration
 ```
 
 This creates a repair migration in the `repair-migration` directory targeting the project's latest migration.
@@ -137,7 +137,7 @@ Since each repair migration is created for a specific live database schema, Serv
 By default, the repair migration system connects to your `development` database using the information specified in your Serverpod config. To use a different database source, the `--mode` option is used.
 
 ```bash
-$ serverpod create-repair-migration --mode production
+serverpod create-repair-migration --mode production
 ```
 
 The command connects and pulls the live database schema from a running server.
@@ -147,7 +147,7 @@ The command connects and pulls the live database schema from a running server.
 Repair migrations can also target a specific migration version by specifying the migration name with the `--version` option.
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0
+serverpod create-repair-migration --version 20230821135718-v1-0-0
 ```
 
 This makes it possible to revert your database schema back to any older migration version.
@@ -162,15 +162,15 @@ The repair migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a repair migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-repair-migration --force
+serverpod create-repair-migration --force
 ```
 
 ### Tag repair migration
 
 Repair migrations can be tagged just like regular migrations. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-repair-migration --tag "reset-migrations"
+serverpod create-repair-migration --tag "reset-migrations"
 ```
 
 This would create a repair migration named `<timestamp>-reset-migrations` in the `repair` directory:
@@ -194,13 +194,13 @@ The `repair` directory only exists if a repair migration has been created and co
 The repair migration is applied using the server runtime. To apply a repair migration, start the server with the `--apply-repair-migration` flag. The repair migration is applied as part of the startup sequence and the framework asserts that each repair migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
 
 The repair migration can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-repair-migration
+dart run bin/main.dart --role maintenance --apply-repair-migration
 ```
 
 If a repair migration is applied at the same time as migrations, the repair migration is applied first.
@@ -214,11 +214,11 @@ Note that data is not rolled back, only the database schema.
 To roll back to a previous migration, first create a repair migration targeting the desired migration version:
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
+serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
 ```
 
 Then apply the repair migration, any repair migration will only be applied once:
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```

docs/06-concepts/10-modules.md

@@ -32,15 +32,15 @@ modules:
 Then run `pub get` and `serverpod generate` from your server's directory (e.g., `mypod_server`) to add the module to your project's deserializer.
 
 ```bash
-$ dart pub get
-$ serverpod generate
+dart pub get
+serverpod generate
 ```
 
 Finally, since modules might include modifications to the database schema, you should create a new database migration and apply it by running `serverpod create-migration`  then `dart bin/main.dart --apply-migrations` from your server's directory.
 
 ```bash
-$ serverpod create-migration
-$ dart bin/main.dart --apply-migrations
+serverpod create-migration
+dart bin/main.dart --apply-migrations
 ```
 
 ### Client setup
@@ -79,13 +79,13 @@ fields:
 With the `serverpod create` command, it is possible to create new modules for code that is shared between projects or that you want to publish to pub.dev. To create a module instead of a server project, pass `module` to the `--template` flag.
 
 ```bash
-$ serverpod create --template module my_module
+serverpod create --template module my_module
 ```
 
 The create command will create a server and a client Dart package. If you also want to add custom Flutter code, use `flutter create` to create a package.
 
 ```bash
-$ flutter create --template package my_module_flutter
+flutter create --template package my_module_flutter
 ```
 
 In your Flutter package, you most likely want to import the client libraries created by `serverpod create`.

docs/06-concepts/11-authentication/04-providers/03-google/01-setup.md

@@ -190,7 +190,7 @@ If your `google-services.json` does not include a web OAuth client entry, you ma
 For a production app you need to get the SHA-1 key from your production keystore! This can be done by running this command: ([Read more](https://support.google.com/cloud/answer/6158849#installedapplications&android&zippy=%2Cnative-applications%2Candroid)).
 
 ```bash
-$ keytool -list -v -keystore /path/to/keystore
+keytool -list -v -keystore /path/to/keystore
 ```
 :::
 
@@ -208,7 +208,7 @@ Navigate to _Clients_ and select the server credentials (the one configured as a
 Force flutter to run on a specific port by running.
 
 ```bash
-$ flutter run -d chrome --web-port=49660
+flutter run -d chrome --web-port=49660
 ```
 :::
 

docs/06-concepts/11-authentication/11-legacy/01-setup.md

@@ -15,7 +15,7 @@ Serverpod's auth module makes it easy to authenticate users through email or 3rd
 Add the module as a dependency to the server project's `pubspec.yaml`.
 
 ```sh
-$ dart pub add serverpod_auth_server
+dart pub add serverpod_auth_server
 ```
 
 Add the authentication handler to the Serverpod instance.
@@ -46,27 +46,27 @@ modules:
 While still in the server project, generate the client code and endpoint methods for the auth module by running the `serverpod generate` command line tool.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 ### Initialize the auth database
 
 After adding the module to the server project, you need to initialize the database. First you have to create a new migration that includes the auth module tables. This is done by running the `serverpod create-migration` command line tool in the server project.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 Start your database container from the server project.
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 Then apply the migration by starting the server with the `apply-migrations` flag.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 The full migration instructions can be found in the [migration guide](../../database/migrations).

docs/06-concepts/11-authentication/11-legacy/04-providers/02-google.md

@@ -119,7 +119,7 @@ Put the file inside the `android/app/` directory and rename it to `google-servic
 For a production app you need to get the SHA-1 key from your production keystore! This can be done by running this command: ([Read more](https://support.google.com/cloud/answer/6158849#installedapplications&android&zippy=%2Cnative-applications%2Candroid)).
 
 ```bash
-$ keytool -list -v -keystore /path/to/keystore
+keytool -list -v -keystore /path/to/keystore
 ```
 
 :::
@@ -136,7 +136,7 @@ Navigate to _Credentials_ under _APIs & Services_ and select the server credenti
 Force flutter to run on a specific port by running.
 
 ```bash
-$ flutter run -d chrome --web-port=49660
+flutter run -d chrome --web-port=49660
 ```
 
 :::