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

attach does not set terminal mode #38648

Open
KenMacD opened this issue Jan 28, 2019 · 0 comments
Open

attach does not set terminal mode #38648

KenMacD opened this issue Jan 28, 2019 · 0 comments

Comments

@KenMacD
Copy link

KenMacD commented Jan 28, 2019

Description

When attaching to an application that uses curses and sets the keypad in application mode (Python: stdscr.keypad(True), C: keypad(stdscr, TRUE) (ex)) the attaching terminal is not sent the control codes to set its mode correctly.

Steps to reproduce the issue:

  1. docker run -it an application that uses curses (for example)
  2. docker attach to this image in a new terminal
  3. Press arrow keys in the original term and the new terminal.

Describe the results you received:

The arrow keys should give the same values in both cases.

Describe the results you expected:

The arrow keys give different values because the second terminal is not sending them in application mode.

Additional information you deem important (e.g. issue happens only occasionally):

This occurs if rtorrent is run in a docker container, making the up and down arrow keys only work in the original terminal.

This occurs and was tested in Linux using rxvt-unicode-256color and xterm. If the terminal always sends the same values then it might not show up in other test cases.

If run in script the DECCKM command can be seen being sent to the first terminal on start [?1h, but the attaching terminal is never sent this control code.

As a workaround tmux can be run and used to re-attach to the original run instead of using docker attach.

Output of docker version:

Client:
 Version:           18.09.1-ce
 API version:       1.39
 Go version:        go1.11.4
 Git commit:        4c52b901c6
 Built:             Thu Jan 10 06:51:04 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.09.1-ce
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.11.4
  Git commit:       4c52b901c6
  Built:            Thu Jan 10 06:50:46 2019
  OS/Arch:          linux/amd64
  Experimental:     false

Output of docker info:

Containers: 2
 Running: 1
 Paused: 0
 Stopped: 1
Images: 114
Server Version: 18.09.1-ce
Storage Driver: btrfs
 Build Version: Btrfs v4.19.1 
 Library Version: 102
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 9f2e07b1fc1342d1c48fe4d7bbb94cb6d1bf278b.m
runc version: 079817cc26ec5292ac375bb9f47f373d33574949
init version: fec3683
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.20.3-arch1-1-ARCH
Operating System: Arch Linux
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 15.42GiB
Name:
ID:
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):

Tested on ARMv7 as well, with the same results.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant