Update deprecated terminal settings

.devcontainer/devcontainer.json

@@ -3,7 +3,7 @@
 	"name": "VS Code Docs",
 	"dockerFile": "Dockerfile",
 	"settings": {
-		"terminal.integrated.shell.linux": "/bin/zsh"
+		"terminal.integrated.defaultProfile.linux": "zsh"
 	},
 	"extensions": [
 		"yzhang.markdown-all-in-one",

docs/containers/ssh.md

@@ -23,7 +23,7 @@ It is also possible to connect to the remote Docker engine directly using SSH tu
 
     * **Linux:** `ssh-agent` is present by default. Do `ssh-add <keyfile>`. Ubuntu was tested; you might have different results on other distributions.
 
-    * **macOS:** `ssh-agent` is present by default, but `ssh-add` does not persist across logins. Do `ssh-add <keyfile>`. We recommend configuring VS Code to run this command on terminal startup with `terminal.integrated.shellArgs.osx` or otherwise configuring a startup script. You can also manually run that command each login.
+    * **macOS:** `ssh-agent` is present by default, but `ssh-add` does not persist across logins. Do `ssh-add <keyfile>`. We recommend configuring VS Code to run this command on terminal startup with `terminal.integrated.profiles.osx` `args` value or otherwise configuring a startup script. You can also manually run that command each login.
 
 1. Verify that your identity is available to the agent with `ssh-add -l`. It should list one or more identities that look something like `2048 SHA256:abcdefghijk somethingsomething (RSA)`. If it does not list any identity, you will not be able to connect. Also, it needs to have the right identity. The Docker CLI working does not mean that the Explorer window will work. The Explorer window uses [dockerode](https://www.npmjs.com/package/dockerode) (which in turn uses [ssh2](https://www.npmjs.com/package/ssh2)), whereas the Docker CLI uses the `ssh` command, and benefits from an automatically inferred configuration.
 

docs/editor/tasks.md

@@ -888,10 +888,12 @@ That was tasks - let's keep going...
 
 ### Can a task use a different shell than the one specified for the Integrated Terminal?
 
-Yes. You can use the `"terminal.integrated.automationShell.*"` setting to set the shell that will be used for all automation in VS Code, which includes Tasks.
+Yes. You can use the `"terminal.integrated.automationProfile.*"` setting to set the shell that will be used for all automation in VS Code, which includes Tasks.
 
 ```json
-    "terminal.integrated.automationShell.windows": "cmd.exe",
+    "terminal.integrated.automationProfile.windows": {
+        "path": "cmd.exe"
+    }
 ```
 
 Alternatively, you can override a task's shell with the `options.shell` property. You can set this per task, globally, or per platform. For example, to use cmd.exe on Windows, your `tasks.json` would include:

docs/remote/attach-container.md

@@ -36,7 +36,7 @@ Both of these files support a subset of `devcontainer.json` properties:
 
     // Set *default* container specific settings.json values on container create.
     "settings": {
-        "terminal.integrated.shell.linux": "/bin/bash"
+        "terminal.integrated.defaultProfile.linux": "bash"
     },
 
     // Add the IDs of extensions you want installed when the container is created.

docs/remote/containers-tutorial.md

@@ -131,7 +131,7 @@ The `devcontainer.json` is basically a config file that determines how your dev
     "customizations": {
         "vscode": {
             "settings": {
-                "terminal.integrated.shell.linux": "/bin/bash"
+                "terminal.integrated.defaultProfile.linux": "bash"
             },
 
             "extensions": [

docs/supporting/troubleshoot-terminal-launch.md

@@ -27,12 +27,12 @@ To troubleshoot Integrated Terminal launch failures in Visual Studio Code, follo
 
 1. **Check your user settings.** Review these `terminal.integrated` [settings](/docs/getstarted/settings.md) that could affect the launch:
 
-   * `terminal.integrated.shell.{platform}` - The path of the shell that the terminal uses.
-   * `terminal.integrated.shellArgs.{platform}` - The command-line arguments when launching the shell process.
+   * `terminal.integrated.defaultProfile.{platform}` - The default shell profile that the terminal uses.
+   * `terminal.integrated.profiles.{platform}` - The defined shell profiles. Sets the shell path and arguments.
    * `terminal.integrated.cwd` - The current working directory (cwd) for the shell process.
    * `terminal.integrated.env.{platform}` - Environment variables that will be added to the shell process.
    * `terminal.integrated.inheritEnv` - Whether new shells should inherit their environment from VS Code.
-   * `terminal.integrated.automationShell.{platform}` - Shell path for automation-related terminal usage like tasks and debug.
+   * `terminal.integrated.automationProfile.{platform}` - Shell profile for automation-related terminal usage like tasks and debug.
    * `terminal.integrated.splitCwd` - Controls the current working directory a split terminal starts with.
    * `terminal.integrated.windowsEnableConpty` - Whether to use ConPTY for Windows terminal process communication.
 
@@ -92,7 +92,13 @@ This can happen if Windows Subsystem for Linux (WSL) is not set up with a valid
 The easy fix for this issue is to use the 64-bit version. If you must use the 32-bit version, you need to use the sysnative path when configuring your shell path instead of System32. Adding this setting should fix the issue:
 
 ```json
-"terminal.integrated.shell.windows": "C:\\Windows\\Sysnative\\cmd.exe"
+{
+   "terminal.integrated.profiles.windows": {
+      "Command Prompt": {
+         "path": "${env:windir}\\Sysnative\\cmd.exe"
+      }
+   }
+}
 ```
 
 ### A native exception occurred