search

devcontainers / cli

A reference implementation for the specification that can create and configure a dev container from a devcontainer.json.
https://containers.dev
MIT License
1.45k stars 203 forks source link

Opening interactive shells via exec subcommand is unresponsive #799

Open ruffsl opened 4 months ago

ruffsl commented 4 months ago

When attempting to open an interactive shell session via the devcontainer exec sub-command, the resulting shell becomes unresponsive after invoking the first command in that shell, as can be viewed via this screen recording:

https://github.com/devcontainers/cli/assets/2293573/01d460d3-a3d2-4f72-863b-6af03ff66631

$ devcontainer --version
0.58.0

Server: Docker Engine - Community Engine: Version: 26.0.0 API version: 1.45 (minimum version 1.24) Go version: go1.21.8 Git commit: 8b79278 Built: Wed Mar 20 15:17:48 2024 OS/Arch: linux/amd64 Experimental: false containerd: Version: 1.6.28 GitCommit: ae07eda36dd25f8a1b98dfbf587313b99c0190bb runc: Version: 1.1.12 GitCommit: v1.1.12-0-g51d5e94 docker-init: Version: 0.19.0 GitCommit: de40ad0


---

Steps to Reproduce:

1. Using the minimal config file as below included in `$(pwd)/.devcontainer/devcontainer.json`
2.  `devcontainer build`
2.  `devcontainer up`
3. `devcontainer exec whoami` to test that container is running with `vscode` printed to stdout
4. `devcontainer exec bash` or use `sh` to spawn an interactive shell
4. enter any valid shell command and not that it immediately becomes unresponsive
5. Choice of shell, terminal emulator, or host machine seems to make no difference

```json
{
    "name": "Ubuntu",
    "image": "mcr.microsoft.com/devcontainers/base:jammy"
}

Note: when attempting to paste commands via CRTL+SHIT+V or move the cursor, one can view the raw escape sequence values for bracketed paste mode or arrow keys presses rendered on the client shell.

ruffsl@box:~/ws/devcontainer_cli_bug$ devcontainer exec bash
vscode ➜ /workspaces/devcontainer_cli_bug $ ^[[200~whoami^[[201~
^C
samruddhikhandale commented 4 months ago

Hi 👋

Thanks for opening a detailed issue.

Choice of shell, terminal emulator, or host machine seems to make no difference

Interesting that I wasn't able to reproduce the issue with @devcontainers/cli 0.58.0. However, my machine configuration is different than yours which could make a difference 👇

@devcontainers/cli 0.58.0. Node.js v16.18.0. darwin 23.4.0 arm64.

Image

Note: when attempting to paste commands via CRTL+SHIT+V or move the cursor, one can view the raw escape sequence values for bracketed paste mode or arrow keys presses rendered on the client shell.

It seems like the terminal is not interpreting the pasted command correctly, and instead is printing the raw escape sequences. This could be due to a misconfiguration in your terminal settings (especially with terminal emulator)

@ruffsl Does the issue reproduce only for mcr.microsoft.com/devcontainers/base:jammy image? Can you test with other images as well? (eg. mcr.microsoft.com/devcontainers/base:bullesye / mcr.microsoft.com/devcontainers/base:focal / ubuntu:latest etc)

Restraint commented 4 months ago

I only get this issue when i use the devcontainer command found at /usr/local/bin/devcontainer on my machine. Presumably the one installed from vscode? Meanwhile, running npx devcontainer exec --workspace-folder . zsh works just fine. Running devcontainer --version yields 0.58.0 on both

ruffsl commented 3 months ago

Can you test with other images as well?

@samruddhikhandale: Yes, this issue persists for those images, as well as my own custom images from ubuntu:24.04, so I'm don't think the base image for the dev container is the common denominator here.

I only get this issue when i use the devcontainer command found at /usr/local/bin/devcontainer on my machine. Presumably the one installed from vscode?

@Restraint: Good find. Yep, this only seems to exhibit itself in the binaries provided by VSCode. If if build the main branch from source, and use that CLI binary instead, the exec sub command works as expected.

~/git/devcontainers/cli$ devcontainer exec bash
node ➜ /workspaces/cli (main) $ whoami
^C
~/git/devcontainers/cli$ node devcontainer.js --version
0.60.0
~/git/devcontainers/cli$ node devcontainer.js exec --workspace-folder . bash
node ➜ /workspaces/cli (main) $ whoami 
node
node ➜ /workspaces/cli (main) $ ls
CHANGELOG.md  CONTRIBUTING.md  README.md              azure-pipelines.yml  devcontainer.js  docs        example-usage  node_modules  scripts  tsconfig.base.json  tsfmt.json
CODEOWNERS    LICENSE.txt      ThirdPartyNotices.txt  build                dist             esbuild.js  images         package.json  src      tsconfig.json       yarn.lock

Update: This issues seem to persist with with the latest CLI binaries installed with the latest version of VSCode:

$ devcontainer --version
0.59.1
ruffsl commented 3 months ago

@samruddhikhandale any update on this? Thanks!

samruddhikhandale commented 3 months ago

Yep, this only seems to exhibit itself in the binaries provided by VSCode.

In my testing, I was using the CLI installed with https://www.npmjs.com/package/@devcontainers/cli. No wonder I wasn't able to reproduce 😅 Thanks @Restraint for pointing out that difference.

@chrmarti Do you know why the CLI behaves differently when installed with NPM versus when it is available in the VS Code library? I wonder if the binaries people are referring to are installed via the Dev Containers Extension, where there might be some special casing with VS Code.

@Restraint @ruffsl Can you both use https://www.npmjs.com/package/@devcontainers/cli to unblock yourselves? Using the CLI installed with the NPM package should ideally be the right way of consuming the CLI. Thanks!

chrmarti commented 2 months ago

This appears to be a bug in the wrapper we have in the Dev Containers extension.

ruffsl commented 2 months ago

Update: Issues still persists with with the latest CLI binaries installed with the latest version of VSCode:

$ code --version
1.90.0
89de5a8d4d6205e5b11647eb6a74844ca23d2573
x64

$ devcontainer --version
0.62.0