Would like to be able to execute interactive command

[hpe-ykoehler]

In my env, developer will likely want to run devcontainer exec bash and then be able to navigate the container and do stuff within using command-line interface.

As such, I think the option to exec the command in interactive mode is important.

[bamurtaugh]

Thanks for opening hpe-ykoehler! Could you share how this is different from the devcontainer exec command currently available?

[hpe-ykoehler]

When I use the devcontainer exec of today to run "bash" I cannot type anything, the output shows the prompt and the container is not accepting inputs.

That is normally because when using docker, to run bash we must use -ti to make the docker knows we require a TTY and tha that the session will be interactive so that it connects the stdin to the container (or someting along those line).

So the test is "devcontainer exec bash" and see that you get a functional terminal, which in my setup I do not get.

[nking-1]

+1 to this request. There are devs I work with who don't use VSCode as their editor but would still find devcontainers useful in their workflow. An interactive shell is essential for them.

In the meantime, it's possible to open a terminal session by using docker container ls to get the running container ID, then run bash with docker exec -it <id> /bin/bash

nk@DESKTOP-LIH0TIU:~/code/vscode-remote-try-rust$ docker container ls
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d5b67fea7ce8 vsc-vscode-remote-try-rust-d007786a17c62e0d1a94f4da56714892-uid "/bin/sh -c 'echo Co…" 5 minutes ago Up 5 minutes kind_brahmagupta

nk@DESKTOP-LIH0TIU:~/code/vscode-remote-try-rust$ docker exec -it d5b67fea7ce8 /bin/bash
root ➜ / $

[zflat]

This works OK from within a workspace directory:

docker exec -it -u $(id -u) $(devcontainer up --workspace-folder . | jq -r .containerId) bash

It will get the ID of a container that was previously started from the Remote - Containers VSCode extension.

[mscottford]

This works OK from within a workspace directory:

docker exec -it -u $(id -u) $(devcontainer up --workspace-folder . | jq -r .containerId) bash

It will get the ID of a container that was previously started from the Remote - Containers VSCode extension.

Thanks for this tip. I had to remove the -u $(id -u) parameter to get this to work. Otherwise, I get output that looks like this:

❯ docker exec -it -u $(id -u) $(devcontainer up --workspace-folder . | jq -r .containerId) bash
[9 ms] @devcontainers/cli 0.9.1.
whoami: cannot find name for user ID 501
rm: cannot remove '/usr/local/share/nvm/current': Permission denied
I have no name!@fe0ad01686b5:/$

I changed to -u vscode to get a prompt as the vscode user.

Also, this doesn't set the working directory to the workspace, you'll need to switch to the workspace directory after you get to the bash prompt, or you'll need to specify the workspace directory using -w. My final command looks something like this:

docker exec -it -u vscode -w "/workspaces/$(basename $(pwd))" $(devcontainer up --workspace-folder . | jq -r .containerId) bash

[pkazmier]

I, too, would like a -i flag to indicate an interactive command. For example, I use the CLI to work with a devcontainer to develop an interactive command line tool, so it would be nice to either be able to exec to run the command. Or, alternatively, it might be nice to have a new subcommand to create an interactive shell—essentially doing a docker exec -it -u vscode CONTAINERID bash.

[behrica]

I would as well add that to run a bash in a devcontainer is the "standard" task, which non-vscode-users will do with a devcontainer.
So supporting an -i flag in devcontainer exec would be very useful.

[mickeahlinder]

I've tried to debug this for a couple of hours today, reversing the CLI code.
I've come to the conclusion that the CLI does indeed initiate docker exec-session using -ti as arguments, but does not read input coming from the cli-host, in other words: The user types a command and presses Enter. However, when hijacking the PTY stream from node-pty and manually sending a command to the process spawned (p.write('ls\r')) works and prints the output.
So the input from the cliHost is "blocked" somewhere.
I would gladly look into this further, but I lack the technical knowledge of how the streams fit together. With some assistance or just some pointing as to where the link might be "broken" I might be able to continue.