Update more links to dev container spec

blogs/2020/07/27/containers-edu.md

@@ -156,7 +156,7 @@ Variables we'd recommend starting off with in a `devcontainer.json` for educatio
 
 Setting up a handful of variables in this file will save your class time in the long run. For example, you can use the `extensions` variable to ensure all your students automatically get the same set of extensions installed. Setting paths can also be challenging or lead to issues on students' computers, but by specifying path information via the `settings` variable, you'll save your class time and ensure their computers' path variables aren't harmed in the process.
 
-There is a table in the [devcontainer.json reference](https://code.visualstudio.com/docs/remote/devcontainerjson-reference) of all available properties you can include in this configuration file.
+There are tables in the [devcontainer.json reference](https://containers.dev/implementors/json_reference) of all available properties you can include in this configuration file.
 
 #### Dockerfile
 

build/sitemap.xml

@@ -850,11 +850,6 @@
         <changefreq>weekly</changefreq>
         <priority>0.8</priority>
     </url>
-    <url>
-        <loc>https://code.visualstudio.com/docs/remote/devcontainerjson-reference</loc>
-        <changefreq>weekly</changefreq>
-        <priority>0.8</priority>
-    </url>
     <url>
         <loc>https://code.visualstudio.com/docs/remote/attach-container</loc>
         <changefreq>weekly</changefreq>

docs/remote/attach-container.md

@@ -9,7 +9,7 @@ DateApproved: 9/1/2022
 ---
 # Attach to a running container
 
-Visual Studio Code can create and start containers for you but that may not match your workflow and you may prefer to "attach" VS Code to an already running Docker container - regardless of how it was started. Once attached, you can install extensions, edit, and debug like you can when you open a folder in a container using [devcontainer.json](/docs/remote/devcontainerjson-reference.md).
+Visual Studio Code can create and start containers for you but that may not match your workflow and you may prefer to "attach" VS Code to an already running Docker container - regardless of how it was started. Once attached, you can install extensions, edit, and debug like you can when you open a folder in a container using [devcontainer.json](https://containers.dev/implementors/json_reference).
 
 ## Attach to a Docker container
 
@@ -55,14 +55,39 @@ Both of these files support a subset of `devcontainer.json` properties:
 }
 ```
 
-See the [attached container config reference](/docs/remote/devcontainerjson-reference.md#attached-container-configuration-reference) for a complete list of properties and their uses.
+See the [attached container config reference](#attached-container-configuration-reference) for a complete list of properties and their uses.
 
 Once saved, whenever you open a container for the first time with the same image / container name, these properties will be used to configure the environment.
 
 > **Tip:** If something is wrong with your configuration, you can also edit it when not attached to the container by selecting **Remote-Containers: Open Attached Container Configuration File...** from the Command Palette (`kbstyle(F1)`) and then picking the image / container name from the presented list.
 
 Finally, if you have extensions you want installed regardless of the container you attach to, you can update `settings.json` to specify a list of [extensions that should always be installed](/docs/remote/containers.md#always-installed-extensions).
 
+## Attached container configuration reference
+
+Attached container configuration files are similar to [devcontainer.json](https://containers.dev/implementors/json_reference) and supports a subset of its properties.
+
+| Property | Type | Description |
+|----------|------|-------------|
+| `workspaceFolder` | string | Sets the default path that VS Code should open when connecting to the container (which is often the path to a volume mount where the source code can be found in the container). Not set by default (an empty window is opened). |
+| `extensions` | array | An array of extension IDs that specify the extensions that should be installed inside the container when it is created. Defaults to `[]`. |
+| `settings` | object | Adds default `settings.json` values into a container/machine specific settings file.  |
+| `forwardPorts` | array | A list of ports that should be forwarded from inside the container to the local machine. |
+| `portsAttributes` | object | Object that maps a port number, `"host:port"` value, range, or regular expression to a set of default options. See [port attributes](https://containers.dev/implementors/json_reference/#port-attributes) for available options. For example: <br />`"portsAttributes": {"3000": {"label": "Application port"}}` |
+| `otherPortsAttributes` | object | Default options for ports, port ranges, and hosts that aren't configured using `portsAttributes`. See [port attributes](https://containers.dev/implementors/json_reference/#port-attributes) for available options. For example: <br /> `"otherPortsAttributes": {"onAutoForward": "silent"}` |
+| `remoteEnv` | object | A set of name-value pairs that sets or overrides environment variables for VS Code (or sub-processes like terminals) but not the container as a whole. Environment and [pre-defined variables](#variables-in-attached-container-configuration-files) may be referenced in the values.<br>For example: `"remoteEnv": { "PATH": "${containerEnv:PATH}:/some/other/path" }` |
+| `remoteUser` | string | Overrides the user that VS Code runs as in the container (along with sub-processes like terminals, tasks, or debugging). Defaults to the user the container as a whole is running as (often `root`). |
+| `userEnvProbe` | enum | Indicates the type of shell to use to "probe" for user environment variables to include in VS Code or other connected tool's processes: `none`, `interactiveShell`, `loginShell`, or `loginInteractiveShell` (default). The specific shell used is based on the default shell for the user (typically bash). For example, bash interactive shells will typically include variables set in `/etc/bash.bashrc` and `~/.bashrc` while login shells usually include variables from `/etc/profile` and `~/.profile`. Setting this property to `loginInteractiveShell` will get variables from all four files. |
+| `postAttachCommand` | string,<br>array | A command string or list of command arguments to run after VS Code attaches to the container. Use `&&` in a string to execute multiple commands. For example, `"yarn install"` or `"apt-get update && apt-get install -y curl"`. The array syntax `["yarn", "install"]` will invoke the command (in this case `yarn`) directly without using a shell. Not set by default. <br>Note that the array syntax will execute the command without a shell. You can [learn more](https://containers.dev/implementors/json_reference/#formatting-string-vs-array-properties) about formatting string vs array properties. |
+
+### Variables in attached container configuration files
+
+Variables can be referenced in certain string values in attached configuration files in the following format: **${variableName}**. The following table is a list of available variables you can use.
+
+| Variable | Properties | Description |
+|----------|---------|----------------------|
+| `${containerEnv:VAR_NAME}` | `remoteEnv` | Value of an existing environment variable inside the container (in this case, `VAR_NAME`) once it is up and running. For example: `"remoteEnv": { "PATH": "${containerEnv:PATH}:/some/other/path" }` |
+
 ## Attach to a container in a Kubernetes cluster
 
 To attach to a container in a Kubernetes cluster, first install the [Kubernetes extension](https://marketplace.visualstudio.com/items?itemName=ms-kubernetes-tools.vscode-kubernetes-tools) and `kubectl` along with the Remote - Containers extension. Then select the Kubernetes explorer from the Activity bar and expand the cluster and Pod where the container you want to attach to resides. Finally, right-click on the container and select **Attach Visual Studio Code** from context menu.
@@ -75,4 +100,4 @@ To attach to a container in a Kubernetes cluster, first install the [Kubernetes
 
 * [Create a Development Container](/docs/remote/create-dev-container.md) - Create a custom container for your work environment.
 * [Advanced Containers](/remote/advancedcontainers/overview.md) - Find solutions to advanced container scenarios.
-* [devcontainer.json reference](/docs/remote/devcontainerjson-reference.md) - Review the `devcontainer.json` schema.
+* [devcontainer.json reference](https://containers.dev/implementors/json_reference) - Review the `devcontainer.json` schema.

docs/remote/containers-tutorial.md

@@ -160,7 +160,7 @@ The above example is taken from the `vscode-remote-try-node` repo we used in the
 | `postCreateCommand`  | A command string or list of command arguments to run after the container is created. |
 | `remoteUser`  | Overrides the user that VS Code runs as in the container (along with sub-processes). Defaults to the `containerUser`.  |
 
-[Full list](/docs/remote/devcontainerjson-reference.md) of `devcontainer.json` options.
+[Full list](https://containers.dev/implementors/json_reference) of `devcontainer.json` options.
 
 ### Congratulations
 

docs/remote/containers.md

@@ -236,7 +236,7 @@ This implies trusting [the machine the Docker daemon runs on](/remote/advancedco
 
 ## Create a devcontainer.json file
 
-VS Code's container configuration is stored in a [devcontainer.json](/docs/remote/devcontainerjson-reference.md) file. This file is similar to the `launch.json` file for debugging configurations, but is used for launching (or attaching to) your development container instead. You can also specify any extensions to install once the container is running or post-create commands to prepare the environment. The dev container configuration is either located under `.devcontainer/devcontainer.json` or stored as a `.devcontainer.json` file (note the dot-prefix) in the root of your project.
+VS Code's container configuration is stored in a [devcontainer.json](https://containers.dev/implementors/json_reference) file. This file is similar to the `launch.json` file for debugging configurations, but is used for launching (or attaching to) your development container instead. You can also specify any extensions to install once the container is running or post-create commands to prepare the environment. The dev container configuration is either located under `.devcontainer/devcontainer.json` or stored as a `.devcontainer.json` file (note the dot-prefix) in the root of your project.
 
 You can use any image, Dockerfile, or set of Docker Compose files as a starting point. Here is a simple example that uses one of the pre-built [VS Code Development Container images](https://hub.docker.com/_/microsoft-vscode-devcontainers):
 
@@ -262,11 +262,11 @@ To learn more about creating `devcontainer.json` files, see [Create a Developmen
 
 ## Dev Container Features (preview)
 
-Development container "Features" are self-contained, shareable units of installation code and dev container configuration. The name comes from the idea that referencing one of them allows you to quickly and easily add more tooling, runtime, or library "Features" into your development container for you or your collaborators to use.
+Development container "Features" are self-contained, shareable units of installation code and dev container configuration. The name comes from the idea that referencing one of them allows you to quickly and easily add more tooling, runtime, or library "Features" into your development container for use by you or your collaborators.
 
 When you use **Remote-Containers: Add Development Container Configuration Files**, you're presented a list of scripts to customize the existing dev container configurations, such as installing Git or the Azure CLI:
 
-![Dev container Features in Command Palette](images/containers/container-features.png)
+![Dev container Features list drop down](images/containers/container-features.png)
 
 When you rebuild and reopen in your container, the Features you selected will be available in your `devcontainer.json`:
 
@@ -284,11 +284,11 @@ You'll get IntelliSense when editing the `"features"` property in the `devcontai
 
 The **Remote-Containers: Configure Container Features** command allows you to update an existing configuration.
 
-The Features sourced in VS Code UI come from the [`devcontainers/features` repository](https://github.com/devcontainers/features).
+The Features sourced in VS Code UI come from the [devcontainers/features repository](https://github.com/devcontainers/features).
 
 ### Creating your own feature
 
-It's also easy to create and publish your own Dev Container Features. Published Features can be stored and shared as [OCI Artifacts](https://github.com/opencontainers/artifacts) from any supporting public or private container registry. You can see the list of current published Features on [containers.dev](https://containers.dev/features.html).
+It's also easy to create and publish your own Dev Container Features. Published Features can be stored and shared as [OCI Artifacts](https://github.com/opencontainers/artifacts) from any supporting public or private container registry. You can see the list of current published Features on [containers.dev](https://containers.dev/features).
 
 A Feature is a self contained entity in a folder with at least a `devcontainer-feature.json` and `install.sh` entrypoint script:
 
@@ -299,11 +299,11 @@ A Feature is a self contained entity in a folder with at least a `devcontainer-f
 |    +-- (other files)
 ```
 
-See the [latest template](https://github.com/devcontainers/feature-template) for instructions on using the dev container CLI to publish your own public or private Features!
+See the [latest template](https://github.com/devcontainers/feature-template) for instructions on using the dev container CLI to publish your own public or private Features.
 
 ### Features proposal and distribution
 
-Features are an active proposal in the open dev container specification. You can review the [Features proposal](https://github.com/devcontainers/spec/issues/61), along with [greater information about how Features work](https://containers.dev/implementors/features/) and their [distribution](https://containers.dev/implementors/features-distribution/).
+Features are an active proposal in the open-source [Development Containers Specification](https://containers.dev). You can review the [Features proposal](https://github.com/devcontainers/spec/issues/61), along with [more information about how Features work](https://containers.dev/implementors/features) and their [distribution](https://containers.dev/implementors/features-distribution).
 
 ## Pre-building dev container images
 
@@ -614,8 +614,7 @@ See the [Advanced container configuration](/remote/advancedcontainers/overview.m
 
 ## devcontainer.json reference
 
-There is a full [devcontainer.json reference](/docs/remote/devcontainerjson-reference.md), where you can review
-the file schema to help you customize your development containers and control how you attach to running containers.
+There is a full [devcontainer.json reference](https://containers.dev/implementors/json_reference), where you can review the file schema to help you customize your development containers and control how you attach to running containers.
 
 ## Known limitations
 
@@ -710,9 +709,9 @@ The following articles may help answer your question:
 
 ### Can I use dev containers outside of VS Code?
 
-As containerizing production workloads becomes commonplace, dev containers have become broadly useful for scenarios beyond VS Code. We're creating the **Development Containers Specification** to empower anyone in any tool to configure a consistent dev environment. It seeks to find ways to enrich existing formats with common development specific settings, tools, and configuration while still providing a simplified, un-orchestrated single container option – so that they can be used as coding environments or for continuous integration and testing.
+As containerizing production workloads becomes commonplace, dev containers have become useful for scenarios beyond VS Code. We're creating the [Development Container Specification](https://containers.dev/implementors/spec) to empower anyone in any tool to configure a consistent development environment. It seeks to find ways to enrich existing formats with common development specific settings, tools, and configurations while still providing a simplified, un-orchestrated single container option – so that they can be used as coding environments or for continuous integration and testing.
 
-You can learn more and review the spec on [containers.dev](https://containers.dev), and you can review active proposals and contribute to the spec in the [devcontainers/spec](https://github.com/devcontainers/spec) repository on GitHub.
+You can learn more and review the specification at [containers.dev](https://containers.dev), and you can review active proposals and contribute to the specification in the [devcontainers/spec](https://github.com/devcontainers/spec) repository on GitHub.
 
 ## Questions or feedback
 
@@ -729,4 +728,4 @@ You can learn more and review the spec on [containers.dev](https://containers.de
 * [Attach to a Running Container](/docs/remote/attach-container.md) - Attach to an already running Docker container.
 * [Create a Development Container](/docs/remote/create-dev-container.md) - Create a custom container for your work environment.
 * [Advanced Containers](/remote/advancedcontainers/overview.md) - Find solutions to advanced container scenarios.
-* [devcontainer.json reference](https://containers.dev/implementors/json_reference/) - Review the `devcontainer.json` schema.
+* [devcontainer.json reference](https://containers.dev/implementors/json_reference) - Review the `devcontainer.json` schema.