docs: restore some config.bin for --help stuff (#1029)

* docs: restore some config.bin for --help stuff

* fix: the one I missed

Author: mshanemc

messages/convert.mdapi.md

@@ -14,11 +14,11 @@ To convert multiple metadata components, either set multiple --metadata <name> f
 
 - Convert metadata formatted files in the specified directory into source formatted files; writes converted files to your default package directory:
 
-  $ sf <%= command.id %> --root-dir path/to/metadata
+  $ <%= config.bin %> <%= command.id %> --root-dir path/to/metadata
 
 - Similar to previous example, but writes converted files to the specified output directory:
 
-  $ sf <%= command.id %> --root-dir path/to/metadata --output-dir path/to/outputdir
+  $ <%= config.bin %> <%= command.id %> --root-dir path/to/metadata --output-dir path/to/outputdir
 
 # flags.root-dir.summary
 

messages/convert.source.md

@@ -4,9 +4,9 @@ Convert source-formatted files into metadata that you can deploy using Metadata
 
 # description
 
-To convert source-formatted files into the metadata format, so that you can deploy them using Metadata API, run this command. Then deploy the metadata using "sf project deploy".
+To convert source-formatted files into the metadata format, so that you can deploy them using Metadata API, run this command. Then deploy the metadata using "<%= config.bin %> project deploy".
 
-To convert Metadata API–formatted files into the source format, run "sf project convert mdapi".
+To convert Metadata API–formatted files into the source format, run "<%= config.bin %> project convert mdapi".
 
 To specify a package name that includes spaces, enclose the name in single quotes.
 
@@ -16,11 +16,11 @@ To convert multiple components, either set multiple --metadata <name> flags or a
 
 - Convert source-formatted files in the specified directory into metadata-formatted files; writes converted files into a new directory:
 
-  $ sf <%= command.id %> --root-dir path/to/source
+  $ <%= config.bin %> <%= command.id %> --root-dir path/to/source
 
 - Similar to previous example, but writes converted files to the specified output directory and associates the files with the specified package:
 
-  $ sf <%= command.id %> --root-dir path/to/source --output-dir path/to/outputdir --package-name 'My Package'
+  $ <%= config.bin %> <%= command.id %> --root-dir path/to/source --output-dir path/to/outputdir --package-name 'My Package'
 
 # flags.api-version.summary
 

messages/delete.source.md

@@ -4,7 +4,7 @@ Delete source from your project and from a non-source-tracked org.
 
 # description
 
-Use this command to delete components from orgs that don’t have source tracking. To remove deleted items from orgs that have source tracking enabled, "sf project deploy start".
+Use this command to delete components from orgs that don’t have source tracking. To remove deleted items from orgs that have source tracking enabled, "<%= config.bin %> project deploy start".
 
 When you run this command, both the local source file and the metadata component in the org are deleted.
 
@@ -14,19 +14,19 @@ To delete multiple metadata components, either set multiple --metadata <name> fl
 
 - Delete all local Apex source files and all Apex classes from the org with alias "my-scratch":
 
-  sf <%= command.id %> --metadata ApexClass --target-org my-scratch
+  <%= config.bin %> <%= command.id %> --metadata ApexClass --target-org my-scratch
 
 - Delete a specific Apex class and a Profile that has a space in it from your default org; don't prompt for confirmation:
 
-  sf <%= command.id %> --metadata ApexClass:MyFabulousApexClass --metadata "Profile: My Profile" --no-prompt
+  <%= config.bin %> <%= command.id %> --metadata ApexClass:MyFabulousApexClass --metadata "Profile: My Profile" --no-prompt
 
 - Run the tests that aren’t in any managed packages as part of the deletion; if the delete succeeds, and the org has source-tracking enabled, update the source tracking information:
 
-  sf <%= command.id %> --metadata ApexClass --test-level RunLocalTests --track-source
+  <%= config.bin %> <%= command.id %> --metadata ApexClass --test-level RunLocalTests --track-source
 
 - Delete the Apex source files in a directory and the corresponding components from your default org:
 
-  sf <%= command.id %> --source-dir force-app/main/default/classes
+  <%= config.bin %> <%= command.id %> --source-dir force-app/main/default/classes
 
 # flags.source-dir.summary
 

messages/delete.tracking.md

@@ -10,23 +10,23 @@ Resets local and remote source tracking so that Salesforce CLI no longer registe
 
 Use the --revision parameter to reset source tracking to a specific revision number of an org source member. To get the revision number, query the SourceMember Tooling API object with the 'data soql' command. For example:
 
-    sf data query --query "SELECT MemberName, MemberType, RevisionCounter FROM SourceMember" --use-tooling-api --target-org my-scratch
+    <%= config.bin %> data query --query "SELECT MemberName, MemberType, RevisionCounter FROM SourceMember" --use-tooling-api --target-org my-scratch
 
 # resetExample
 
 - Reset source tracking for the org with alias "my-scratch":
 
-  $ sf <%= command.id %> --target-org my-scratch
+  $ <%= config.bin %> <%= command.id %> --target-org my-scratch
 
 - Reset source tracking to revision number 30 for your default org:
 
-  $ sf <%= command.id %> --revision 30
+  $ <%= config.bin %> <%= command.id %> --revision 30
 
 # deleteExample
 
 - Delete local source tracking for the org with alias "my-scratch":
 
-  $ sf <%= command.id %> --target-org my-scratch
+  $ <%= config.bin %> <%= command.id %> --target-org my-scratch
 
 # deleteSummary
 

messages/deploy.metadata.cancel.md

@@ -12,11 +12,11 @@ Run this command by either passing it a job ID or specifying the --use-most-rece
 
 - Cancel a deploy operation using a job ID:
 
-      sf <%= command.id %> --job-id 0Af0x000017yLUFCA2
+      <%= config.bin %> <%= command.id %> --job-id 0Af0x000017yLUFCA2
 
 - Cancel the most recent deploy operation:
 
-      sf <%= command.id %> --use-most-recent
+      <%= config.bin %> <%= command.id %> --use-most-recent
 
 # flags.job-id.summary
 
@@ -26,10 +26,10 @@ Job ID of the deploy operation you want to cancel.
 
 These commands return a job ID if they time out or you specified the --async flag:
 
-- sf project deploy start
-- sf project deploy validate
-- sf project deploy quick
-- sf project deploy cancel
+- <%= config.bin %> project deploy start
+- <%= config.bin %> project deploy validate
+- <%= config.bin %> project deploy quick
+- <%= config.bin %> project deploy cancel
 
 The job ID is valid for 10 days from when you started the deploy operation.
 
@@ -47,15 +47,15 @@ Number of minutes to wait for the command to complete and display results.
 
 # flags.wait.description
 
-If the command continues to run after the wait period, the CLI returns control of the terminal window to you. To resume watching the cancellation, run "sf project deploy resume". To check the status of the cancellation, run "sf project deploy report".
+If the command continues to run after the wait period, the CLI returns control of the terminal window to you. To resume watching the cancellation, run "<%= config.bin %> project deploy resume". To check the status of the cancellation, run "<%= config.bin %> project deploy report".
 
 # flags.async.summary
 
 Run the command asynchronously.
 
 # flags.async.description
 
-The command immediately returns the control of the terminal to you. This way, you can continue to use the CLI. To resume watching the cancellation, run "sf project deploy resume". To check the status of the cancellation, run "sf project deploy report".
+The command immediately returns the control of the terminal to you. This way, you can continue to use the CLI. To resume watching the cancellation, run "<%= config.bin %> project deploy resume". To check the status of the cancellation, run "<%= config.bin %> project deploy report".
 
 # error.CannotCancelDeploy
 

messages/deploy.metadata.md

@@ -8,36 +8,36 @@ You must run this command from within a project.
 
 Metadata components are deployed in source format by default. Deploy them in metadata format by specifying the --metadata-dir flag, which specifies the root directory or ZIP file that contains the metadata formatted files you want to deploy.
 
-If your org allows source tracking, then this command tracks the changes in your source. Some orgs, such as production orgs, never allow source tracking. Source tracking is enabled by default on scratch and sandbox orgs; you can disable source tracking when you create the orgs by specifying the --no-track-source flag on the "sf org create scratch|sandbox" commands.
+If your org allows source tracking, then this command tracks the changes in your source. Some orgs, such as production orgs, never allow source tracking. Source tracking is enabled by default on scratch and sandbox orgs; you can disable source tracking when you create the orgs by specifying the --no-track-source flag on the "<%= config.bin %> org create scratch|sandbox" commands.
 
 To deploy multiple metadata components, either set multiple --metadata <name> flags or a single --metadata flag with multiple names separated by spaces. Enclose names that contain spaces in one set of double quotes. The same syntax applies to --manifest and --source-dir.
 
 # examples
 
 - Deploy local changes not in the org; uses your default org:
 
-      sf <%= command.id %>
+      <%= config.bin %> <%= command.id %>
 
 - Deploy all source files in the "force-app" directory to an org with alias "my-scratch"; show only concise output, in other words don't print a list of all the source that was deployed:
 
-      sf <%= command.id %>  --source-dir force-app --target-org my-scratch --concise
+      <%= config.bin %> <%= command.id %>  --source-dir force-app --target-org my-scratch --concise
 
 - Deploy all the Apex classes and custom objects that are in the "force-app" directory. The list views, layouts, etc, that are associated with the custom objects are also deployed. Both examples are equivalent:
 
-      sf <%= command.id %> --source-dir force-app/main/default/classes force-app/main/default/objects
-      sf <%= command.id %> --source-dir force-app/main/default/classes --source-dir force-app/main/default/objects
+      <%= config.bin %> <%= command.id %> --source-dir force-app/main/default/classes force-app/main/default/objects
+      <%= config.bin %> <%= command.id %> --source-dir force-app/main/default/classes --source-dir force-app/main/default/objects
 
 - Deploy all Apex classes that are in all package directories defined in the "sfdx-project.json" file:
 
-      sf <%= command.id %> --metadata ApexClass
+      <%= config.bin %> <%= command.id %> --metadata ApexClass
 
 - Deploy a specific Apex class; ignore any conflicts between the local project and org (be careful with this flag, because it will overwrite the Apex class in the org if there are conflicts!):
 
-      sf <%= command.id %> --metadata ApexClass:MyApexClass --ignore-conflicts
+      <%= config.bin %> <%= command.id %> --metadata ApexClass:MyApexClass --ignore-conflicts
 
 - Deploy specific Apex classes that match a pattern; in this example, deploy Apex classes whose names contain the string "MyApex". Also ignore any deployment warnings (again, be careful with this flag! You typically want to see the warnings):
 
-      sf <%= command.id %> --metadata 'ApexClass:MyApex*' --ignore-warnings
+      <%= config.bin %> <%= command.id %> --metadata 'ApexClass:MyApex*' --ignore-warnings
 
 - Deploy a custom object called ExcitingObject that's in the SBQQ namespace:
 
@@ -49,20 +49,20 @@ To deploy multiple metadata components, either set multiple --metadata <name> fl
 
 - Deploy all custom objects and Apex classes found in all defined package directories (both examples are equivalent):
 
-      sf <%= command.id %> --metadata CustomObject ApexClass
-      sf <%= command.id %> --metadata CustomObject --metadata ApexClass
+      <%= config.bin %> <%= command.id %> --metadata CustomObject ApexClass
+      <%= config.bin %> <%= command.id %> --metadata CustomObject --metadata ApexClass
 
 - Deploy all Apex classes and a profile that has a space in its name:
 
-      sf <%= command.id %> --metadata ApexClass --metadata "Profile:My Profile"
+      <%= config.bin %> <%= command.id %> --metadata ApexClass --metadata "Profile:My Profile"
 
 - Deploy all components listed in a manifest:
 
-      sf <%= command.id %> --manifest path/to/package.xml
+      <%= config.bin %> <%= command.id %> --manifest path/to/package.xml
 
 - Run the tests that aren’t in any managed packages as part of a deployment:
 
-      sf <%= command.id %> --metadata ApexClass --test-level RunLocalTests
+      <%= config.bin %> <%= command.id %> --metadata ApexClass --test-level RunLocalTests
 
 # flags.pre-destructive-changes.summary
 
@@ -114,7 +114,7 @@ Number of minutes to wait for command to complete and display results.
 
 # flags.wait.description
 
-If the command continues to run after the wait period, the CLI returns control of the terminal window to you and returns the job ID. To resume the deployment, run "sf project deploy resume". To check the status of the deployment, run "sf project deploy report".
+If the command continues to run after the wait period, the CLI returns control of the terminal window to you and returns the job ID. To resume the deployment, run "<%= config.bin %> project deploy resume". To check the status of the deployment, run "<%= config.bin %> project deploy report".
 
 # flags.manifest.summary
 
@@ -176,7 +176,7 @@ Run the command asynchronously.
 
 # flags.async.description
 
-The command immediately returns the job ID and control of the terminal to you. This way, you can continue to use the CLI. To resume the deployment, run "sf project deploy resume". To check the status of the deployment, run "sf project deploy report".
+The command immediately returns the job ID and control of the terminal to you. This way, you can continue to use the CLI. To resume the deployment, run "<%= config.bin %> project deploy resume". To check the status of the deployment, run "<%= config.bin %> project deploy report".
 
 # flags.metadata-dir.summary
 

messages/deploy.metadata.preview.md

@@ -6,31 +6,31 @@ Preview a deployment to see what will deploy to the org, the potential conflicts
 
 You must run this command from within a project.
 
-The command outputs a table that describes what will happen if you run the "sf project deploy start" command. The table lists the metadata components that will be deployed and deleted. The table also lists the current conflicts between files in your local project and components in the org. Finally, the table lists the files that won't be deployed because they're included in your .forceignore file.
+The command outputs a table that describes what will happen if you run the "<%= config.bin %> project deploy start" command. The table lists the metadata components that will be deployed and deleted. The table also lists the current conflicts between files in your local project and components in the org. Finally, the table lists the files that won't be deployed because they're included in your .forceignore file.
 
-If your org allows source tracking, then this command displays potential conflicts between the org and your local project. Some orgs, such as production org, never allow source tracking. Source tracking is enabled by default on scratch and sandbox orgs; you can disable source tracking when you create the orgs by specifying the --no-track-source flag on the "sf org create scratch|sandbox" commands.
+If your org allows source tracking, then this command displays potential conflicts between the org and your local project. Some orgs, such as production org, never allow source tracking. Source tracking is enabled by default on scratch and sandbox orgs; you can disable source tracking when you create the orgs by specifying the --no-track-source flag on the "<%= config.bin %> org create scratch|sandbox" commands.
 
 To preview the deployment of multiple metadata components, either set multiple --metadata <name> flags or a single --metadata flag with multiple names separated by spaces. Enclose names that contain spaces in one set of double quotes. The same syntax applies to --manifest and --source-dir.
 
 # examples
 
-- NOTE: The commands to preview a deployment and actually deploy it use similar flags. We provide a few preview examples here, but see the help for "sf project deploy start" for more examples that you can adapt for previewing.
+- NOTE: The commands to preview a deployment and actually deploy it use similar flags. We provide a few preview examples here, but see the help for "<%= config.bin %> project deploy start" for more examples that you can adapt for previewing.
 
 - Preview the deployment of source files in a directory, such as force-app, to your default org:
 
-      sf <%= command.id %>  --source-dir force-app
+      <%= config.bin %> <%= command.id %>  --source-dir force-app
 
 - Preview the deployment of all Apex classes to an org with alias "my-scratch":
 
-      sf <%= command.id %> --metadata ApexClass --target-org my-scratch
+      <%= config.bin %> <%= command.id %> --metadata ApexClass --target-org my-scratch
 
 - Preview deployment of a specific Apex class:
 
-      sf <%= command.id %> --metadata ApexClass:MyApexClass
+      <%= config.bin %> <%= command.id %> --metadata ApexClass:MyApexClass
 
 - Preview deployment of all components listed in a manifest:
 
-      sf <%= command.id %> --manifest path/to/package.xml
+      <%= config.bin %> <%= command.id %> --manifest path/to/package.xml
 
 # flags.only-ignored.summary