From f59ee4e125f78c43cd19a6055d1e06554c8fd94b Mon Sep 17 00:00:00 2001 From: Dan Barr Date: Mon, 8 Aug 2022 11:56:36 -0400 Subject: [PATCH] Fix capitalizations in docs Fixes various capitalizations in the docs * Ex: VMware, Linux/Unix, PowerShell, some abbreviations Also, Prettier auto-formatted away some trailing spaces. --- website/content/docs/cli/destroy.mdx | 2 +- website/content/docs/cli/halt.mdx | 4 +- website/content/docs/cli/powershell.mdx | 2 +- website/content/docs/cli/ssh.mdx | 4 +- website/content/docs/disks/hyperv/usage.mdx | 2 +- .../docs/disks/vmware/common-issues.mdx | 8 +-- website/content/docs/disks/vmware/index.mdx | 8 +-- website/content/docs/disks/vmware/usage.mdx | 2 +- .../content/docs/experimental/vagrant_go.mdx | 66 +++++++++---------- .../docs/providers/virtualbox/boxes.mdx | 2 +- .../vmware/vagrant-vmware-utility.mdx | 2 +- .../docs/provisioning/ansible_local.mdx | 2 +- .../docs/provisioning/puppet_apply.mdx | 2 +- .../docs/synced-folders/virtualbox.mdx | 4 +- website/content/docs/triggers/usage.mdx | 2 +- .../content/docs/vagrantfile/ssh_settings.mdx | 2 +- website/content/docs/vagrantfile/tips.mdx | 2 +- .../content/vagrant-cloud/request-limits.mdx | 2 +- website/data/docs-nav-data.json | 2 +- 19 files changed, 60 insertions(+), 60 deletions(-) diff --git a/website/content/docs/cli/destroy.mdx b/website/content/docs/cli/destroy.mdx index 3a46fa37a..25e42f2d5 100644 --- a/website/content/docs/cli/destroy.mdx +++ b/website/content/docs/cli/destroy.mdx @@ -15,7 +15,7 @@ destroys all resources that were created during the machine creation process. After running this command, your computer should be left at a clean state, as if you never created the guest machine in the first place. -For linux-based guests, Vagrant uses the `shutdown` command to gracefully +For Linux-based guests, Vagrant uses the `shutdown` command to gracefully terminate the machine. Due to the varying nature of operating systems, the `shutdown` command may exist at many different locations in the guest's `$PATH`. It is the guest machine's responsibility to properly populate the `$PATH` with diff --git a/website/content/docs/cli/halt.mdx b/website/content/docs/cli/halt.mdx index dcb16a13d..995edeaaf 100644 --- a/website/content/docs/cli/halt.mdx +++ b/website/content/docs/cli/halt.mdx @@ -16,13 +16,13 @@ Vagrant will first attempt to gracefully shut down the machine by running the guest OS shutdown mechanism. If this fails, or if the `--force` flag is specified, Vagrant will effectively just shut off power to the machine. -For linux-based guests, Vagrant will: +For Linux-based guests, Vagrant will: 1. Attempt to detect and use Systemd to execute `systemctl poweroff`; but otherwise, 2. Fallback to using the `shutdown` command to gracefully terminate the machine. -Due to the varying nature of operating systems, these executables may exist at many +Due to the varying nature of operating systems, these executables may exist at many different locations in the guest's `$PATH`. It is the guest machine's responsibility to properly populate the `$PATH` with directory containing the `shutdown` command. diff --git a/website/content/docs/cli/powershell.mdx b/website/content/docs/cli/powershell.mdx index b6c292489..ed1d19df9 100644 --- a/website/content/docs/cli/powershell.mdx +++ b/website/content/docs/cli/powershell.mdx @@ -2,7 +2,7 @@ layout: docs page_title: vagrant powershell - Command-Line Interface description: |- - The "vagrant powershell" command is used to open a powershell prompt running + The "vagrant powershell" command is used to open a PowerShell prompt running inside the guest machine. --- diff --git a/website/content/docs/cli/ssh.mdx b/website/content/docs/cli/ssh.mdx index 5ad8b7340..57a63ca03 100644 --- a/website/content/docs/cli/ssh.mdx +++ b/website/content/docs/cli/ssh.mdx @@ -38,7 +38,7 @@ Connection to 127.0.0.1 closed. $ ``` -On multi-machine setups, you can login to each vm using the name as displayed +On multi-machine setups, you can login to each VM using the name as displayed on `vagrant status` ```shell-session @@ -135,5 +135,5 @@ from Pageant will not be available for forwarding when using the `vagrant ssh` command. Third party programs exist to allow the SSH executable to access Pageant -by creating a unix socket for the SSH executable to read. For more information +by creating a Unix socket for the SSH executable to read. For more information please see [ssh-pageant](https://github.com/cuviper/ssh-pageant). diff --git a/website/content/docs/disks/hyperv/usage.mdx b/website/content/docs/disks/hyperv/usage.mdx index 671bb48d0..b18267a94 100644 --- a/website/content/docs/disks/hyperv/usage.mdx +++ b/website/content/docs/disks/hyperv/usage.mdx @@ -29,7 +29,7 @@ For examples of how to use the disk feature with Hyper-V, please refer to the Most options are used for either creating or attaching a hard disk to your guest. Vagrant supports most options for these operations. You should be able to define -the powershell specific argument to a given Hyper-V command in the provider_config +the PowerShell specific argument to a given Hyper-V command in the provider_config hash, and Vagrant should properly pass it along to the command. To define a provider specific option, please refer to the [Disk Options documentation page](/docs/disks/configuration) for more info. diff --git a/website/content/docs/disks/vmware/common-issues.mdx b/website/content/docs/disks/vmware/common-issues.mdx index aaaf8e91a..98de817ff 100644 --- a/website/content/docs/disks/vmware/common-issues.mdx +++ b/website/content/docs/disks/vmware/common-issues.mdx @@ -1,6 +1,6 @@ --- layout: docs -page_title: Common Issues - Disks VMWare Provider +page_title: Common Issues - Disks VMware Provider description: |- HashiCorp develops an official VMware Fusion and VMware Workstation provider for Vagrant. This provider allows Vagrant to power VMware based machines and @@ -10,13 +10,13 @@ description: |- # Common Issues and Troubleshooting -This page lists some common issues people run into with Vagrant and VMWare +This page lists some common issues people run into with Vagrant and VMware as well as solutions for those issues. ## Are my disks attached? A handy way to figure out what disks are attached (or not attached) to your guest -is to open up the VMWare GUI and open up the guest settings and selecting the +is to open up the VMware GUI and open up the guest settings and selecting the disks options. ## How many disks can I attach? @@ -37,5 +37,5 @@ If snapshots exist for a VM, disk functionality will be limited. Vagrant will re an error for any actions that are limited due to the existence of snapshots. In order to restore functionality the snapshots must be removed. This can be done using the [`vagrant snapshot delete`](/docs/cli/snapshot) command. To delete all snapshots -for a VMWare backed VM try `vagrant cap provider delete_all_snapshots --target `. +for a VMware backed VM try `vagrant cap provider delete_all_snapshots --target `. Note once a snapshot is deleted, it can not be restored. diff --git a/website/content/docs/disks/vmware/index.mdx b/website/content/docs/disks/vmware/index.mdx index 67c9c291a..431be4d64 100644 --- a/website/content/docs/disks/vmware/index.mdx +++ b/website/content/docs/disks/vmware/index.mdx @@ -1,6 +1,6 @@ --- layout: docs -page_title: Disks for VMWare Provider +page_title: Disks for VMware Provider description: |- HashiCorp develops an official VMware Fusion and VMware Workstation provider for Vagrant. This provider allows Vagrant to power VMware based machines and @@ -8,7 +8,7 @@ description: |- offers. --- -# VMWare +# VMware ~> **Warning!** This feature is experimental and may break or change in between releases. Use at your own risk. It currently is not officially @@ -24,11 +24,11 @@ Please note that `VAGRANT_EXPERIMENTAL` is an environment variable. For more information about this flag visit the [Experimental docs page](/docs/experimental/) for more info. Without this flag enabled, any disks defined will not be configured. -Because of how VMWare handles disk management, a Vagrant guest _must_ be powered +Because of how VMware handles disk management, a Vagrant guest _must_ be powered off for any changes to be applied to a guest. If you make a configuration change with a guests disk, you will need to `vagrant reload` the guest for any changes to be applied. -For more information on how to use VMWare to configure disks for a guest, refer +For more information on how to use VMware to configure disks for a guest, refer to the [general usage](/docs/disks/usage) and [configuration](/docs/disks/configuration) guide for more information. diff --git a/website/content/docs/disks/vmware/usage.mdx b/website/content/docs/disks/vmware/usage.mdx index 731d035ac..dc04e3f6c 100644 --- a/website/content/docs/disks/vmware/usage.mdx +++ b/website/content/docs/disks/vmware/usage.mdx @@ -1,6 +1,6 @@ --- layout: docs -page_title: Usage - Disks VMWare Provider +page_title: Usage - Disks VMware Provider description: |- HashiCorp develops an official VMware Fusion and VMware Workstation provider for Vagrant. This provider allows Vagrant to power VMware based machines and diff --git a/website/content/docs/experimental/vagrant_go.mdx b/website/content/docs/experimental/vagrant_go.mdx index a770867d6..c5839b553 100644 --- a/website/content/docs/experimental/vagrant_go.mdx +++ b/website/content/docs/experimental/vagrant_go.mdx @@ -7,9 +7,9 @@ description: Introduction to Vagrant Go # Vagrant Go Vagrant-go is Vagrant implemented in Go. This version of Vagrant is compatible -with Ruby based Vagrant plugins as well as Vagrantfiles. However, there are +with Ruby based Vagrant plugins as well as Vagrantfiles. However, there are some significant changes to how Vagrant-go works which make it NOT interchangeable -with Vagrant (Ruby). +with Vagrant (Ruby). ~> **Warning!** Vagrant-go is in alpha and should be expected to be unstable. Users are not recommended to use Vagrant-go for normal day to day operations. @@ -21,7 +21,7 @@ machines managed with Vagrant (Ruby) can not be managed by Vagrant-go and vice v ### Vagrant-go binary -The Vagrant-go binary is shipped with the Vagrant installer. In order to run the Vagrant-go +The Vagrant-go binary is shipped with the Vagrant installer. In order to run the Vagrant-go binary do: ``` @@ -32,14 +32,14 @@ $ vagrant-go global-status Vagrant-go still depends on Vagrant-ruby being available in order to run Ruby plugins and for parsing Vagrantfiles. So, Vagrant-go runs Vagrant-ruby as a server in a subprocess, -providing it access to all the Ruby functionality. +providing it access to all the Ruby functionality. ### Scopes Vagrant-go has a notion of an information hierarchy. There are three main components: **Target**: A target is the most specific component in the information hierarchy. It -represents the guest that Vagrant may manipulate. It is similar to the notion of a +represents the guest that Vagrant may manipulate. It is similar to the notion of a Vagrant Machine. **Project**: A project is similar to the concept of an Environment. It represents @@ -47,7 +47,7 @@ a group of targets. A project may have plugins installed that are not available to other projects. A project directory is any directory that has a Vagrantfile. **Basis**: The basis is the most general component. It represents the root of the Vagrant -execution environment and may contain multiple projects. A user may define multiple basis' +execution environment and may contain multiple projects. A user may define multiple basis' for their installation. Plugins installed into the basis will be available to all projects within the basis. Vagrantfiles setup in the basis will be applied to all projects. @@ -56,7 +56,7 @@ within the basis. Vagrantfiles setup in the basis will be applied to all project The default Vagrant-go data directory and config directory have changed to meet the [XDG specification](https://pkg.go.dev/github.com/adrg/xdg). The data directory is now at the XDG data home. The config directory is now at the -XDG config home. In addition, project level information is no longer available in +XDG config home. In addition, project level information is no longer available in `PROJECT_DIR/.vagrant`. Instead, this information is available with the data and config dirs. The form of these directories is as follows: @@ -65,8 +65,8 @@ The form of these directories is as follows: |- $XDG_CONFIG_DIR \- default # basis name |- Vagrantfile # a basis level Vagrantfile will be applied to all machines in the basis - \- project - \- project_one # project name + \- project + \- project_one # project name \- target |- target_one # target name |- target_two @@ -78,9 +78,9 @@ The form of these directories is as follows: ``` |- $XDG_DATA_DIR - |- data.db # Vagrant database + |- data.db # Vagrant database \- default # basis name - |- insecure_private_key + |- insecure_private_key \- boxes # box directory \- hashicorp-VAGRANTSLASH-bionic64 # box name \- 1.0.282 # box version @@ -90,7 +90,7 @@ The form of these directories is as follows: |- metadata.json |- ubuntu-18.04-amd64-disk001.vmdk \- project - \- project_one # project name + \- project_one # project name \- target |- target_one # target name |- target_two @@ -100,14 +100,14 @@ The form of these directories is as follows: |- a |- b - + ``` -Vagrant-go does not have knowledge of the Vagrant-ruby data directories so does not +Vagrant-go does not have knowledge of the Vagrant-ruby data directories so does not have access to that data and vice versa. Both Vagrant-go and Vagrant-ruby -respect the [Vagrant environment variables](/docs/other/environmental-variables/) for -setting data directory paths. However, the layout and content of these directories -are different for Vagrant-go and Vagrant-ruby. +respect the [Vagrant environment variables](/docs/other/environmental-variables/) for +setting data directory paths. However, the layout and content of these directories +are different for Vagrant-go and Vagrant-ruby. ~> **Warning!** Vagrant-go users should not attempt to use an existing `VAGRANT_HOME` directory as it may corrupt it. @@ -125,13 +125,13 @@ at `$XDG_DATA_DIR`. The ramifications of this are: The machine index for Vagrant-go is backed by the `data.db` in the data directory. The ramifications of this are: -- Vagrant-go and Vagrant-ruby do not share a machine index. They have no knowledge of - each other, so machines you bring up in one will not be available in the other. There is +- Vagrant-go and Vagrant-ruby do not share a machine index. They have no knowledge of + each other, so machines you bring up in one will not be available in the other. There is currently no way to “import” or “export” a machine index entry ## Installing Go Vagrant plugins -Vagrant-go can load external plugins that are packaged as executables. Plugins can be +Vagrant-go can load external plugins that are packaged as executables. Plugins can be launched from the basis (`VAGRANT_CONFIG_DIR/plugins`) or the project directory (`VAGRANT_PROJECT/.vagrant/plugins`). @@ -148,31 +148,31 @@ The `-c` argument does work to specify a single command to run. For example: vagrant ssh -c "echo hello world" ``` -Users may still access the Vagrant machine over ssh by running the ssh command. For example: +Users may still access the Vagrant machine over SSH by running the ssh command. For example: ``` -# Get the ssh configuration for the target machine -vagrant ssh-config +# Get the SSH configuration for the target machine +vagrant ssh-config -# Use the info provided to ssh into the target machine using the ssh command +# Use the info provided to SSH into the target machine using the ssh command ssh vagrant@ -p -i ``` ### `vagrant plugin` command only manipulates Ruby plugins The Vagrant plugin command uses bundler to manage Ruby based plugins. To install/uninstall -go based plugins, users must manually add the plugin binary to the plugins path. +go based plugins, users must manually add the plugin binary to the plugins path. Uninstalling Ruby Vagrant plugins does not currently work. ### Vagrant does not work on Windows -The go plugin setup currently is built on unix sockets. So, Vagrant-go is not expected to +The go plugin setup currently is built on Unix sockets. So, Vagrant-go is not expected to work on Windows. This will be addressed in a future release. ### Secret interactive input Vagrant relies on secret interactive input to allow users to pass in SMB credentials when -using SMB synced folders. Currently, interactive input works for Vagrant-go, however, the -user input is not hidden. Users who wish to use SMB folders and avoid exposing their +using SMB synced folders. Currently, interactive input works for Vagrant-go, however, the +user input is not hidden. Users who wish to use SMB folders and avoid exposing their credentials can work around this issue by specifying the [credentials in the Vagrantfile](/docs/synced-folders/smb/) ### Concurrent Vagrant runs don’t work @@ -181,17 +181,17 @@ Only one Vagrant-go process may run at a time. ### Puppet and Chef provisioners do not work -These provisioners require Vagrant to modify synced folders on the fly during a Vagrant run. +These provisioners require Vagrant to modify synced folders on the fly during a Vagrant run. This capability will not be implemented for 2.3.0, so, these provisioners will not work as expected. -### Each machine must specify their own ssh port for multi machine environments +### Each machine must specify their own SSH port for multi machine environments Currently, Vagrant-go does not check for port collisions when forwarding ports. Instead, it -will allow for multiple forwarded ports to be defined on the same host port. This results in -the ssh ports for machines to all be assigned to the same default port if none is specified. +will allow for multiple forwarded ports to be defined on the same host port. This results in +the SSH ports for machines to all be assigned to the same default port if none is specified. This causes Vagrant to time out when connecting to a machine in multimachine environments. To -avoid this issue you may specify the ssh port for the machines, for example: +avoid this issue you may specify the SSH port for the machines, for example: ``` Vagrant.configure("2") do |config| config.vm.define "one" do |c| diff --git a/website/content/docs/providers/virtualbox/boxes.mdx b/website/content/docs/providers/virtualbox/boxes.mdx index 3e2692e17..229020da9 100644 --- a/website/content/docs/providers/virtualbox/boxes.mdx +++ b/website/content/docs/providers/virtualbox/boxes.mdx @@ -57,7 +57,7 @@ must be installed so that things such as shared folders can function. Installing guest additions also usually improves performance since the guest OS can make some optimizations by knowing it is running within VirtualBox. -Before installing the guest additions, you will need the linux kernel headers +Before installing the guest additions, you will need the Linux kernel headers and the basic developer tools. On Ubuntu, you can easily install these like so: diff --git a/website/content/docs/providers/vmware/vagrant-vmware-utility.mdx b/website/content/docs/providers/vmware/vagrant-vmware-utility.mdx index 337b584f8..35b84be14 100644 --- a/website/content/docs/providers/vmware/vagrant-vmware-utility.mdx +++ b/website/content/docs/providers/vmware/vagrant-vmware-utility.mdx @@ -117,7 +117,7 @@ $ sudo sv start vagrant-vmware-utility ## Utility Service Configuration When installing the Vagrant VMware utility service, a configuration file is generated -that is used when the process is started. On windows, this can be found at: +that is used when the process is started. On Windows, this can be found at: ```text C:\ProgramData\HashiCorp\vagrant-vmware-desktop\config\service.hcl diff --git a/website/content/docs/provisioning/ansible_local.mdx b/website/content/docs/provisioning/ansible_local.mdx index 5e835c8d8..eba4c7f73 100644 --- a/website/content/docs/provisioning/ansible_local.mdx +++ b/website/content/docs/provisioning/ansible_local.mdx @@ -168,7 +168,7 @@ This section lists the _specific_ options for the Ansible Local provisioner. In ### Install Galaxy Roles in a path owned by root -~> **Disclaimer:** This tip is not a recommendation to install galaxy roles out of the vagrant user space, especially if you rely on ssh agent forwarding to fetch the roles. +~> **Disclaimer:** This tip is not a recommendation to install galaxy roles out of the vagrant user space, especially if you rely on SSH agent forwarding to fetch the roles. Be careful that `ansible-galaxy` command is executed by default as vagrant user. Setting `galaxy_roles_path` to a folder like `/etc/ansible/roles` will fail, and `ansible-galaxy` will extract the role a second time in `/home/vagrant/.ansible/roles/`. Then if your playbook uses `become` to run as `root`, it will fail with a _"role was not found"_ error. diff --git a/website/content/docs/provisioning/puppet_apply.mdx b/website/content/docs/provisioning/puppet_apply.mdx index 7c8b14a31..41c9b690e 100644 --- a/website/content/docs/provisioning/puppet_apply.mdx +++ b/website/content/docs/provisioning/puppet_apply.mdx @@ -90,7 +90,7 @@ Vagrant.configure("2") do |config| end ``` -~> `puppet` need to be installed in the guest vm. +~> `puppet` needs to be installed in the guest VM. By default, Vagrant will configure Puppet to look for manifests in the "manifests" folder relative to the project root, and will use the diff --git a/website/content/docs/synced-folders/virtualbox.mdx b/website/content/docs/synced-folders/virtualbox.mdx index 22af785b4..bf06f29c5 100644 --- a/website/content/docs/synced-folders/virtualbox.mdx +++ b/website/content/docs/synced-folders/virtualbox.mdx @@ -18,11 +18,11 @@ the guest to the host and vice versa. ## Options - `automount` (boolean) - If true, the `--automount` flag will be used when - using the VirtualBox tools to share the folder with the guest vm. Defaults to false + using the VirtualBox tools to share the folder with the guest VM. Defaults to false if not present. - `SharedFoldersEnableSymlinksCreate` (boolean) - If false, will disable the - ability to create symlinks with the given virtualbox shared folder. Defaults to + ability to create symlinks with the given VirtualBox shared folder. Defaults to true if the option is not present. ## Caveats diff --git a/website/content/docs/triggers/usage.mdx b/website/content/docs/triggers/usage.mdx index 760c8094e..03b1d6220 100644 --- a/website/content/docs/triggers/usage.mdx +++ b/website/content/docs/triggers/usage.mdx @@ -94,7 +94,7 @@ running either `vagrant destroy` or `vagrant halt` would stop tinyproxy. ### Ruby Option -Triggers can also be defined to run Ruby, rather than bash or powershell. An +Triggers can also be defined to run Ruby, rather than bash or PowerShell. An example of this might be using a Ruby option to get more information from the `VBoxManage` tool. In this case, we are printing the `ostype` defined for thte guest after it has been brought up. diff --git a/website/content/docs/vagrantfile/ssh_settings.mdx b/website/content/docs/vagrantfile/ssh_settings.mdx index 8faf595fa..8aa431283 100644 --- a/website/content/docs/vagrantfile/ssh_settings.mdx +++ b/website/content/docs/vagrantfile/ssh_settings.mdx @@ -44,7 +44,7 @@ defaults are typically fine, but you can fine tune whatever you would like. - `config.ssh.extra_args` (array of strings) - This settings value is passed directly into the ssh executable. This allows you to pass any arbitrary commands to do things such - as reverse tunneling down into the ssh program. These options can either be + as reverse tunneling down into the SSH program. These options can either be single flags set as strings such as `"-6"` for IPV6 or an array of arguments such as `["-L", "8008:localhost:80"]` for enabling a tunnel from host port 8008 to port 80 on guest. **Note:** This option only affects the `ssh` command or instances diff --git a/website/content/docs/vagrantfile/tips.mdx b/website/content/docs/vagrantfile/tips.mdx index 328e5da07..704ae09e2 100644 --- a/website/content/docs/vagrantfile/tips.mdx +++ b/website/content/docs/vagrantfile/tips.mdx @@ -54,7 +54,7 @@ every node will actually provision with the same text. This is an easy mistake to make, and Vagrant cannot really protect against it, so the best we can do is mention it here. -## Overwrite host locale in ssh session +## Overwrite host locale in SSH session Usually, host locale environment variables are passed to guest. It may cause failures if the guest software do not support host locale. One possible solution diff --git a/website/content/vagrant-cloud/request-limits.mdx b/website/content/vagrant-cloud/request-limits.mdx index cb3ca48a3..4b4d369d5 100644 --- a/website/content/vagrant-cloud/request-limits.mdx +++ b/website/content/vagrant-cloud/request-limits.mdx @@ -23,7 +23,7 @@ If you have received a 429 HTTP status code in the response to your request, you - **X-RateLimit-Limit**: The current maximum number of requests allowed from your client. - **X-RateLimit-Remaining**: How many requests you have remaining in the time window. -- **X-RateLimit-Reset**: The unix timestamp for when the window resets. +- **X-RateLimit-Reset**: The Unix timestamp for when the window resets. ## My use case requires more requests. What do I do? diff --git a/website/data/docs-nav-data.json b/website/data/docs-nav-data.json index 47f0dcc50..0b0f0c883 100644 --- a/website/data/docs-nav-data.json +++ b/website/data/docs-nav-data.json @@ -474,7 +474,7 @@ ] }, { - "title": "VMWare", + "title": "VMware", "routes": [ { "title": "Overview",