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

Fix escape-keys by preserving input if invalid #22943

Merged
merged 1 commit into from May 25, 2016

Conversation

vdemeester
Copy link
Member

Currently, using a custom detach key with an invalid sequence, eats a part of the sequence, making it weird and difficult to enter some key sequence 🐯.

This fixes by keeping the input read when trying to see if it's the key sequence or not, and "writing" then is the key sequence is not the right one, preserving the initial input 🐹.

$ docker run --detach-keys=a,b,c -it busybox /bin/sh
/ #
# press a and a on the keyboard
/ # aa
/ #
# press a, b and d
/ # abd
# press a, b and c
# escape \o/

Fixes #21769

/cc @thaJeztah @cpuguy83 @LK4D4 @runcom @calavera

🐸

Signed-off-by: Vincent Demeester vincent@sbr.pm

@vdemeester vdemeester changed the title Fix escape-keys by preserving input in invalid Fix escape-keys by preserving input if invalid May 24, 2016
@duglin
Copy link
Contributor

duglin commented May 24, 2016

+1 see: #15666 (comment)

@thaJeztah
Copy link
Member

Heh, it works. Bit of a weird side-effect is that typing a twice, will not output the first a, until the second a is pressed. Guess that's ok, because using a,b,c as detach-key is not really a smart choice

@duglin
Copy link
Contributor

duglin commented May 24, 2016

any chance of getting some testcases?

@vdemeester
Copy link
Member Author

@duglin I'm thinking of it, but I'm not sure how still... 😓

@thaJeztah
Copy link
Member

Perhaps you can add the "test" case to the commit message at least

@duglin
Copy link
Contributor

duglin commented May 24, 2016

@vdemeester you may get some inspiration from the tests that use a tty - e.g. TestRunAttachDetach
or TestRunAttachDetachFromConfig

@vdemeester
Copy link
Member Author

@duglin oh you are right. Remembered the way we pty to send input and detach the container but I did not remembered if we check the output content or not… and it seems we do \o/. Test incoming 👼.

Currently, using a custom detach key with an invalid sequence, eats a
part of the sequence, making it weird and difficult to enter some key
sequence.

This fixes by keeping the input read when trying to see if it's the key
sequence or not, and "writing" then is the key sequence is not the right
one, preserving the initial input.

Signed-off-by: Vincent Demeester <vincent@sbr.pm>
@vdemeester
Copy link
Member Author

Updated with tests 😉

@LK4D4
Copy link
Contributor

LK4D4 commented May 25, 2016

LGTM
ping @duglin

@calavera
Copy link
Contributor

LGTM

@calavera calavera merged commit 60abc96 into moby:master May 25, 2016
@vdemeester vdemeester deleted the 21769-fix-detach-keys branch May 25, 2016 17:01
@@ -484,7 +484,9 @@ func copyEscapable(dst io.Writer, src io.ReadCloser, keys []byte) (written int64
nr, er := src.Read(buf)
if nr > 0 {
// ---- Docker addition
preservBuf := []byte{}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Trying to follow the flow here, but it seems to me that "preservBuf" shouldn't be needed since it MUST match the keys, right? meaning if we're on the 3rd char of 'keys' then preservBuf must be the same as the first 2 chars of keys, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@duglin hum it matches a part of the key, true, until the last wrong key is entered. Could have done something with keys, i and the latest read but it failed a little less readable to me 😅

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yea, I just wanted to avoid all of the alloc's and appends as we work our way thru the input.

liusdu pushed a commit to liusdu/moby that referenced this pull request Oct 30, 2017
Currently, using a custom detach key with an invalid sequence, eats a
part of the sequence, making it weird and difficult to enter some key
sequence.

This fixes by keeping the input read when trying to see if it's the key
sequence or not, and "writing" then is the key sequence is not the right
one, preserving the initial input.

(backport from moby#22943)

Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Signed-off-by: Wentao Zhang <zhangwentao234@huawei.com>
(cherry-pick from 0fb6190)
liusdu pushed a commit to liusdu/moby that referenced this pull request Oct 30, 2017
Fix escape-keys by preserving input if invalid

Currently, using a custom detach key with an invalid sequence, eats a
part of the sequence, making it weird and difficult to enter some key
sequence.

This fixes by keeping the input read when trying to see if it's the key
sequence or not, and "writing" then is the key sequence is not the right
one, preserving the initial input.

<br>

(backport from <a href="moby#22943" rel="nofollow noreferrer" target="_blank">https://github.com/moby/moby/pull/22943</a>)

<br>

Signed-off-by: Vincent Demeester <a href="mailto:vincent@sbr.pm">vincent@sbr.pm</a>   

Signed-off-by: Wentao Zhang <a href="mailto:zhangwentao234@huawei.com">zhangwentao234@huawei.com</a> 

(cherry-pick from <a href="/docker/docker/commit/0fb6190243d6101f96283e487cd4911142a05483" data-original="0fb6190243d6101f96283e487cd4911142a05483" data-link="false" data-project="7713" data-commit="0fb6190243d6101f96283e487cd4911142a05483" data-reference-type="commit" title="" class="gfm gfm-commit has-tooltip" data-original-title="Fix escape-keys by preserving input if invalid">0fb61902</a>)



See merge request docker/docker!629
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

The behavior of the prefix of the detachkey, it is undocumented intended behavior or BUG ?
6 participants