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

exec sh (shell) with tty not processing escape chars #1063

Closed
Masber opened this issue Oct 28, 2022 · 2 comments · Fixed by #983
Closed

exec sh (shell) with tty not processing escape chars #1063

Masber opened this issue Oct 28, 2022 · 2 comments · Fixed by #983
Labels
wontfix This will not be worked on

Comments

@Masber
Copy link

Masber commented Oct 28, 2022

Current and expected behavior

Current behaviour

I have a code like this

pub async fn connect_to_console() -> Result<(), Box<dyn Error>> {

    let client = get_k8s_client_programmatically().await?;

    let pods_api: Api<Pod> = Api::namespaced(client, "services");

    let console_pod_name = "test";

    let command = vec!["bash"];

    let mut attached = pods_api.exec(
        &console_pod_name, 
        command,
        &AttachParams::default()
            .container("console-node")
            .stdin(true)
            .stdout(true)
            .stderr(false)
            .tty(true)
    ).await?;

    let mut user_input;
    let stdin = std::io::stdin();
    
    let mut stdin_writer = attached.stdin().unwrap();
    let mut stdout_stream = tokio_util::io::ReaderStream::new(attached.stdout().unwrap());

    let mut next_stdout;
    let mut stdout;

    user_input = String::new();
    
    let rt = Runtime::new().unwrap();
    rt.spawn(async move {
        loop {
            stdin.read_line(&mut user_input).unwrap();
            stdin_writer.write_all(format!("{}", user_input).as_bytes()).await.unwrap();
        }
    }); 

    loop {
        // Read command output
        next_stdout = stdout_stream.next().await;
        stdout = String::from_utf8(next_stdout.unwrap()?.to_vec()).unwrap();
        print!("{}", stdout);
        std::io::stdout().flush().unwrap();
    }
}

I can connect to the container

nobody@cray-console-node-2:/> ps
    PID TTY          TIME CMD
 385929 pts/470  00:00:00 bash
 385953 pts/470  00:00:00 ps

However, when I press the up arrow key, I don't see the last command used but instead the command prints ^[[A

Expected behaviour

when I run kubectl exec -it ... -- bash I can open an interactive session in bash and use the arrow keys to navigate through the shell history

Possible solution

No response

Additional context

In addition, when I press Ctrl+C my application exists, when I do that in a shell, it just prints ^C but it does not exit kubectl. My impression is that my app is still connected to the pty slave

Environment

$ kubectl version --short
Client Version: v1.22.1
Server Version: v1.20.13

Configuration and features

kube = { version = "0.74.0", features = ["runtime", "derive", "native-tls", "ws"] }
k8s-openapi = { version = "0.15.0", features = ["v1_24"] }

Affected crates

No response

Would you like to work on fixing this bug?

No response

@Masber Masber added the bug Something isn't working label Oct 28, 2022
@Masber Masber changed the title running a shell not processing escaped chars exec sh (shell) with tty not processing escape chars Oct 28, 2022
@kazk kazk removed the bug Something isn't working label Nov 1, 2022
@kazk
Copy link
Member

kazk commented Nov 1, 2022

I believe this is out of scope of kube as a library. You can use crates like crossterm in your application to handle them.

I haven't tested, but #983 includes a working example.

@clux clux added the wontfix This will not be worked on label Nov 1, 2022
@clux
Copy link
Member

clux commented Nov 1, 2022

Yeah, deferring to crossterm here should be the way to go. The above PR is very nicely plugging into crossterm in an example to do this, so going to close this when that gets merged (because while full handling of escape chars is out of scope for us, we do need to handle terminal size).

@Masber Masber closed this as completed Nov 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants