swaymsg exec nvim corrupts Linux VT

[neon64]

If I run

$ swaymsg exec nvim

in a terminal emulator inside sway, then exit sway, I get some really weird results. It is as if neovim has started up inside the linux terminal (e.g.: /dev/tty1) while sway is still running, and then when I exit sway I can simultaneously see neovim UI as well as my shell prompt, and I can't reliably exit either of them because they're somehow both in control of the tty.

Expected behaviour would be that neovim doesn't start, similar to when I run nvim& in a terminal. I would imagine this has something to do with neovim thinking it is running in 'interactive mode' inside /dev/tty1, when it really shouldn't be because /dev/tty1 is currently hidden and sway is running on top and capturing all user input.

I should mention - I know I need to start an editor like neovim inside a terminal emulator e.g.: swaymsg exec alacritty -e nvim if I want to actually be able to use it. However it still feels like a bug that running the 'wrong sort of executable' with swaymsg exec (i.e.: not a GUI app) produces such a corrupted state in my linux VT. The same thing happens with vi, and I assume vim (though I haven't tried vim because I don't have it installed)

sway version

sway --version gives

sway version 1.0

however pacman reports 1.1.1-1. I'm pretty sure I'm running the latest version since I needed to install swaybg before my background showed again.

[ascent12]

I know I need to start an editor like neovim inside a terminal emulator e.g.: swaymsg exec alacritty -e nvim if I want to actually be able to use it. However it still feels like a bug that running the 'wrong sort of executable' with swaymsg exec (i.e.: not a GUI app) produces such a corrupted state in my linux VT

You're right. It's probably because clients are inheriting our stdin/stdout which refer to /dev/ttyX, and the process thinks it can just use it as normal.
We should probably give them /dev/null instead, or otherwise capture their output and do something else with it.

[neon64]

On the other hand, it is perhaps nice that the stdout of apps like waybar show up in the console. Maybe the output should be redirected to some sort of log file or the system log so it isn't just lost?

[emersion]

On the other hand, it is perhaps nice that the stdout of apps like waybar show up in the console.

I kind of agree. Better not to discard logs.

Maybe the output should be redirected to some sort of log file or the system log so it isn't just lost?

No, this isn't our responsibility.

[FreeFull]

What if stdout is left as-is, but stdin is closed/changed to /dev/null? I imagine most interactive programs like nvim will refuse to start without stdin.

[emersion]

This is probably acceptable.

[mcoffin]

What about adding some options to exec that control the pipes that are connected to child?

[ascent12]

exec is handled by just running the command through /bin/sh -c, so you could just add your pipes as normal there:

exec my-prog 2>&1 >my-prog.log

With that, I think it makes even more sense to just give them /dev/null for all of stdin/stdout/stderr. If a user cares about the output, pipe it somewhere else in the exec command.

[rumpelsepp]

What about adding some options to exec that control the pipes that are connected to child?

No need for this IMO. I use a script to start graphical programs which basically does this:

swaymsg -t command exec "systemd-cat -t ${cmd[0]} ${cmd[@]}"

stderr/stdout get redirected to the systemd journal and are tagged with the program name.