Change:
'waitMarkerFilePath': { type: 'string' }, 'locale': { type: 'string', cat: 'o', args: 'locale', description: localize('locale', "The locale to use (e.g. en-US or zh-TW).") }, 'user-data-dir': { type: 'string', cat: 'o', args: 'dir', description: localize('userDataDir', "Specifies the directory that user data is kept in. Can be used to open multiple distinct instances of Code.") }, <ins> 'shell-integration': { type: 'string', cat: 'o', args: ['bash', 'pwsh', 'zsh'], description: localize('shellIntergation', "Print the shell integration script file path for the specified shell.") }, </ins> 'help': { type: 'boolean', cat: 'o', alias: 'h', description: localize('help', "Print usage.") }, 'extensions-dir': { type: 'string', deprecates: ['extensionHomePath'], cat: 'e', args: 'dir', description: localize('extensionHomePath', "Set the root path for extensions.") },

Discussion:
Currently install is a little cumbersome, for example: We should also make sure these cases are covered: Remote development extensions - injection works currently but manual install doesn't talk about the server paths Regular SSH - it's not so easy to get the shell integration script to the remote machine
Hi, I’m thinking about another way, in addition to the CLI mentioned above: how about creating a package (deb/rpm) with only directory? This way I only need to install this on the server if I want to SSH to it without remote development (assuming that for some reason I don’t want remote development), since I don’t need the other part of VS Code. This can even go into Debian/Fedora because it is pure MIT, and the package doesn’t have any dependency. I understand that this won’t serve all users (e.g. Windows Server users), so the CLI-way still works as a catch-all.
The deb/rpm approach isn't great as that's a bunch of overhead building and maintaining the packages, additionally if we keep the script bundled with VS Code then we're able to make breaking changes without many consequences, even new features could break old version of VS Code so it's best to keep them in sync using the same package. I'll think about how we can support SSH better when not using the Remote - SSH extension. Now that you remote, I realize the remote development case isn't covered by manual install currently as it uses desktop paths, we'll need to make sure that's covered as well.
The installation instructions at the link below are broken for what I have tested (Linux local and Remote): ,LINUX%20AND%20MACOS,-The%20script%20below When inside Remote - WSL or Remote - SSH (probably Containers too), the Resources Dir can be found with: vs : required to step back a folder from a file ( fails)calling is better than since it at least warns the user if the path can't be 't required In such case, the latter snippet also needs to be adjusted: And when not running through Remote, I wasn't able to find such a file in a Linux .deb installation. Even by following the original instructions, which would probably resolve to a path like: which isn't valid too. The correct path would be instead. And, in such case, the latter snippet would be correct.

thanks for the info, this is what we're planning for the improved experience in : This will also work on the server so the remote extensions will be covered the same.
I'm actually worried about perf here. Running will be slow in many systems, slow enough to notice lag when launching a shell. Given that this always returns the same value every time we execute it... could we perhaps do something similar to ?
installing it directly like the command there isn't portable across system though. We are looking into having the CLI redone in rust which will make it plenty fast enough as we won't need to launch node. I also considered having it in the .sh file itself, but that wouldn't work unless the cli is sourced, not run, and it also wouldn't work at all in pwsh since our CLI is a batch script.