Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Opening interactive shells via exec subcommand is unresponsive #799

Open
ruffsl opened this issue Apr 12, 2024 · 7 comments
Open

Opening interactive shells via exec subcommand is unresponsive #799

ruffsl opened this issue Apr 12, 2024 · 7 comments
Assignees
Labels
bug Something isn't working

Comments

@ruffsl
Copy link

ruffsl commented Apr 12, 2024

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:

simplescreenrecorder-2024-04-12_09.04.59.mp4

  • Dev Container CLI Version:
$ devcontainer --version
0.58.0
  • VSCode Version:
Version: 1.88.0
Commit: 5c3e652f63e798a5ac2f31ffd0d863669328dc4c
Date: 2024-04-03T13:25:57.039Z
Electron: 28.2.8
ElectronBuildId: 27744544
Chromium: 120.0.6099.291
Node.js: 18.18.2
V8: 12.0.267.19-electron.0
OS: Linux x64 6.5.0-26-generic
  • Local OS Version: Linux x64 6.5.0-26-generic
  • Remote OS Version: Linux x64 6.5.0-26-generic
  • Remote Extension/Connection Type: Containers (v0.354.0)
  • Docker Version:
$ docker version
Client: Docker Engine - Community
 Version:           26.0.0
 API version:       1.45
 Go version:        go1.21.8
 Git commit:        2ae903e
 Built:             Wed Mar 20 15:17:48 2024
 OS/Arch:           linux/amd64
 Context:           default

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
  3. devcontainer up
  4. devcontainer exec whoami to test that container is running with vscode printed to stdout
  5. devcontainer exec bash or use sh to spawn an interactive shell
  6. enter any valid shell command and not that it immediately becomes unresponsive
  7. Choice of shell, terminal emulator, or host machine seems to make no difference
{
	"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
Copy link
Member

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
Copy link

Restraint commented Apr 17, 2024

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
Copy link
Author

ruffsl commented May 15, 2024

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
Copy link
Author

ruffsl commented May 30, 2024

@samruddhikhandale any update on this? Thanks!

@samruddhikhandale
Copy link
Member

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
Copy link
Contributor

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

@chrmarti chrmarti self-assigned this May 31, 2024
@chrmarti chrmarti added the bug Something isn't working label May 31, 2024
@ruffsl
Copy link
Author

ruffsl commented Jun 16, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants