nom sometimes breaks line wrapping in tmux

[dasJ]

Hey, so I will try to explain the exact issue but I don't really know how to nail this down any further.
My use case is pretty much a shell script like this:

nix-store nix-store --realise --log-format internal-json -v … 2> >(nom --json)
result/bin/switch-to-configuration

I usually run this in tmux, but sometimes that breaks line wrapping.
What happens is that rather than the newline creating a new line, the cursor stays at the rightmost column and just prints all characters in that position.
This is especially noticable with long lines of services being started/stopped.
The issue also persists when the commands are done and I get thrown back into my shell.

An issue is that this doesn't always happen, only some times. I assume it's related to what is being outputted (like long build names and whatnot) so it doesn't always trigger.

One thing of note is that I usually use ttyctl -f in zsh, which means that my stty settings should be reset once a command is done (and the prompt is being drawn). This is why I assume it's not stty-related and rather something else.

I use tmux 3.3a, zsh 5.9 and nom 2.1.1.

Please tell me if there's anything to narrow that issue down.

[maralorn]

Huh, that sounds annoying. The first thing that would help me would be a screenshot of the problem.

[dasJ]

Visible in the "would restart the following units" where it says .servicee

[maralorn]

Okay, so the problem here is, that nom does not restore the correct terminal behavior after exiting?

[dasJ]

Yes, that's correct. stty looks the same so I don't know what could be different. reset fixes the issues btw.

[maralorn]

I have no clue. It sounds like some data being output affects tmux. I don’t know what that could be. I don’t think e.g. that nom truncates anything that could be a control code. But maybe it is some weird interference between a log line e.g. with color codes and a nom control code to print the table?

You say stty looks the same, but maybe we can fix this by saving the terminal state at the program's start and unconditionally restoring it later? No clue, whether that’s realistic.