\n isn't triggering Enter even when doing wezterm cli send-text --no-paste

[weiying-chen]

What Operating System(s) are you running on?

Linux Wayland

Which Wayland compositor or X11 Window manager(s) are you using?

Mutter

WezTerm version

20240127-113634-bbcac864

Ask your question!

When I run this command:

wezterm cli send-text --no-paste "echo Test\n"

I get this:

➜  wezterm cli send-text --no-paste "echo Test\n"
echo test\n%
➜  echo test\n

The \n doesn't trigger an Enter (carriage return) as mentioned here.

Notes:

• I'm using zsh on Ubuntu.
• I also tried \r, but I get the same result.

[weiying-chen]

This works:

echo ":open ${fpath}\r" | wezterm cli send-text --no-paste

[psnelgrove-r7]

Today I ran into the same thing. My plan was to combine watchexec with sending a :reload\r message to Helix to reload the editor on a file that was being generated.

I'm not sure how to debug something like this (strace or similar I'm sure), but it's either echo sending the bytes differently to stdout or wezterm is interpreting them differently from stdin.

I'm at the point of blowing my budget for tinkering for a perceived optimization in my workflow, but if I can debug a little more later I will.

[psnelgrove-r7]

So the implementation of the command is dead simple.

let data = match self.text {
    Some(text) => text,
    None => {
        let mut text = String::new();
        std::io::stdin()
            .read_to_string(&mut text)
            .context("reading stdin")?;
        text
    }
};

So I'd wager then that it's something with how the clap parser handles the string.

[psnelgrove-r7]

Alright, really need to get back to work but I think this is close to the answer. When clap loads up the string the escaped characters are being interpreted rather than a raw string. However the stdin stream is a sequence of bytes.

https://users.rust-lang.org/t/parsing-whitespace-vs-their-escape-sequences/88771