1
0
mirror of synced 2025-12-23 11:54:18 -05:00

Scannability: Codespaces introductory content (#54688)

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: hubwriter <hubwriter@github.com>
This commit is contained in:
Ben Ahmady
2025-03-11 12:14:17 +00:00
committed by GitHub
parent cba2b19d71
commit 1aea5879b0
31 changed files with 112 additions and 74 deletions

View File

@@ -29,7 +29,7 @@ If you don't want to use the default shell, you can open a new terminal session
If you want to use a shell that isn't already installed in the base image or dev container configuration for a codespace, you can install a new shell.
If you're using the default dev container image, look for installation instructions for Ubuntu Linux. If you just want to use a different shell for one session, you can use the command line to install the shell in the codespace you're working in. However, you may lose programs you have installed if you rebuild the container in the codespace. For more information, see [AUTOTITLE](/codespaces/getting-started/deep-dive#about-the-directory-structure-of-a-codespace).
If you're using the default dev container image, look for installation instructions for Ubuntu Linux. If you just want to use a different shell for one session, you can use the command line to install the shell in the codespace you're working in. However, you may lose programs you have installed if you rebuild the container in the codespace. For more information, see [AUTOTITLE](/codespaces/about-codespaces/deep-dive#about-the-directory-structure-of-a-codespace).
A more robust option for installing new shells is to include the installation commands either in a dotfiles repository, or as a lifecycle command such as `postCreateCommand` in a `devcontainer.json` file. You should use a dotfiles repository to install a shell you want to use in all your own codespaces, and a `devcontainer.json` file for a shell that contributors to a specific repository should have installed. For more information, see [AUTOTITLE](/codespaces/setting-your-user-preferences/personalizing-github-codespaces-for-your-account#dotfiles) and [AUTOTITLE](/codespaces/setting-up-your-project-for-codespaces/adding-a-dev-container-configuration/introduction-to-dev-containers).
@@ -119,7 +119,7 @@ When you have connected to the codespace, for most shells, you can use the comma
With most shells, you have the option of using a configuration file, such as `.bashrc`, to configure the shell with your preferred settings. These settings can include things like aliases and environment variables.
By default, codespaces contain predefined configuration for the shells that come preinstalled. For example, the home directory in a codespace contains `.bashrc` and `.zshrc` files. You can change the contents of these files then use a command like `source ~/.bashrc` to update your shell configuration. However, you will lose any changes to these files if you rebuild the container in a codespace. For more information, see [AUTOTITLE](/codespaces/getting-started/deep-dive#about-the-directory-structure-of-a-codespace).
By default, codespaces contain predefined configuration for the shells that come preinstalled. For example, the home directory in a codespace contains `.bashrc` and `.zshrc` files. You can change the contents of these files then use a command like `source ~/.bashrc` to update your shell configuration. However, you will lose any changes to these files if you rebuild the container in a codespace. For more information, see [AUTOTITLE](/codespaces/about-codespaces/deep-dive#about-the-directory-structure-of-a-codespace).
Generally, you should use a dotfiles repository to configure shells with your preferred settings. The setup in your dotfiles applies to all codespaces you create, and persists over rebuilds of the container. For more information, see [AUTOTITLE](/codespaces/setting-your-user-preferences/personalizing-github-codespaces-for-your-account#dotfiles).