No way to input single "ctrl-p" keypress

[cjao]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

BUG

Description

While inside a terminal inside a container (such as toolbox), pressing "ctrl-p" does nothing while pressing it again sends two "ctrl-p" events to the terminal. This behavior interferes with the standard keybindings of common programs like emacs (where ctrl-p normally scrolls up one line) or bash (where ctrl-p steps back in the command history). Here is a simple demonstration of the problem.

1. podman run --rm -ti fedora-toolbox:30 bash

2. echo 1

3. echo 2

4. echo 3

5. Observe that "ctrl-p" does nothing while pressing it again returns echo 2 instead of echo 3.

Alternatively, check that using "ctrl-p" only allows one to scroll up two lines at a time in emacs.

One workaround would be to change the "detach-keys" sequence from "ctrl-p,ctrl-q" to something that hopefully does not conflict with any other program. But it would be better to just send one "ctrl-p" event for every two invocations of "ctrl-p".

Additional info:

• Running Fedora 30
• rpm -q podman yields

podman-1.6.1-2.fc30.x86_64

[rhatdan]

@haircommander @giuseppe @mheon Is this conmon/podman waiting for a sequence to disconnect from the container?

man podman run
...
       When  attached  in the tty mode, you can detach from the container (and
       leave it running)  using  a  configurable  key  sequence.  The  default
       sequence  is  ctrl-p,ctrl-q.   Configure  the  keys  sequence using the
       --detach-keys option, or specifying it in  the  libpod.conf  file:  see
       libpod.conf(5) for more information.

We might need to either disable this feature or setup alternative key mappings.
I agree the ctrl-p is common for use within bash/emacs settings.

[rhatdan]

@debarshiray WDYT?

[mheon]

This is the CopyDetachable code in Podman

[rhatdan]

Is there an easy way for toolbox to disable this?

[mheon]

Reading the code right now: it seems like it pauses the copy until it can check the buffer fully for C-p C-q if a C-p is detected. Once it can check, if it is not that key sequence, it's copied in its entirely - so sending C-p C-a for example would result in both keys being send.

The difficulty with special-casing C-p C-p is that we don't guarantee that the detach sequence is two keys only. We support, say, C-p C-q C-r as a detach sequence - for that case, would we expect that C-p C-p C-p sends a single C-p?

[mheon]

Actually, the loop would probably terminate early, in the case of 3 keys - so C-p C-p would still work.

[rhatdan]

The think is, how would I run podman and tell it I don't intend to detach. Another would be to put a strange squence. Could toolbox specifiy alt-; or something like that, so it would not be a common sequence used for bash recall.

[mheon]

I think that setting detach keys to "" (empty string) in libpod.conf will get you no detach keys. That has its own disadvantages, in that there's no way to escape an attach session.

[rhatdan]

Sure, But can toolbox just execute

podman run --detach-keys ""
to do the same.

I don't think toolbox expects people to detach from toolboxes. But I will let @debarshiray comment.

[debarshiray]

Wow, I use ctrl+p in Emacs and Bash all the time but I never noticed this before today. I guess I just don't spent enough quality time inside a Toolbox shell. :)

Yes, I agree. We don't expect people to want to detach a container while running an interactive shell.

[mheon]

For now, simplest solution would be for Toolbox to override detach keys, then. I don't know if exec allows this yet; we can add it if it doesn't.

[haircommander]

exec does allow this!

[debarshiray]

It doesn't look like --detach-keys "" unsets the shortcut. I tried:

$ podman run --env TERM=$TERM --detach-keys "" -it --rm registry.fedoraproject.org/f31/fedora-toolbox:31 /bin/bash

I also tried --detach-keys=.

[debarshiray]

Grepping around in the code, I found:

DefaultDetachKeys = "ctrl-p,ctrl-q"

func processDetachKeys(keys string) ([]byte, error) {
	// Check the validity of the provided keys first
	if len(keys) == 0 {
		keys = DefaultDetachKeys
	}
	detachKeys, err := term.ToBytes(keys)
	if err != nil {
		return nil, errors.Wrapf(err, "invalid detach keys")
	}
	return detachKeys, nil
}

So, it doesn't look like --detach-keys "" unsets the shortcut, at least not currently.

[rhatdan]

Yes lets open a PR to change the DefaultDetatchKeys to be set at a higher level and then to return empty list with ""

[stove-panini]

Hey all, any progress on this? @rhatdan do you have a link to the PR you mentioned?

[github-actions]

This issue had no activity for 30 days. In the absence of activity or the "do-not-close" label, the issue will be automatically closed within 7 days.

[rhatdan]

@stove-panini Looks like this is fixed in upstream, although we have another issue.