flatpak-spawn --host doesn't work with apps requiring tty/pty

[JayDoubleu]

flatpak-spawn --host sudo echo
sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
sudo: a password is required

I've also noticed some apps like neovim are not rendering properly and glitch when being resized. It feels like working in serial console in general.

[TingPing]

I'm not sure if flatpak-spawn should be changed but here is an example project and some documentation about properly running a PTY on the host:

https://gitlab.gnome.org/chergert/flatterm/-/blob/master/fp-vte-util.c#L33-56

[JayDoubleu]

I see. Is this also related to flatpak/flatpak#3697 then ?
flatpak-spawn is heavily used by fedora toolbx users.

[TingPing]

It looks the same yes.

[JayDoubleu]

IMHO If would be great if flatpak-spawn could be changed to remediate this. I find myself running quite a few programs using it.

[TingPing]

I'm not familiar enough with it to do it atm, but I'll review a patch adapting those solutions, perhaps with a new flag to avoid breaking anything.

[1player]

I have been working on an alternative reimplementation of flatpak-spawn --host: https://github.com/1player/host-spawn

Improvements over flatpak-spawn:

• Allocates a pty for the spawned process, which fixes this issue.
• Passes through SIGWINCH signals, to handle terminal resizing.
• Passes through some env variables (such as TERM)

It's a reimplementation because I was more comfortable with exploring this problem in Go instead of hacking the original C code base, but it's in the public domain so feel free to use my code to fix flatpak-spawn.

[smcv]

I've implemented a similar pseudo-terminal bridge in GObject-flavoured C as part of steam-runtime-launch-client, a development/debugging tool shipped as part of Steam, which is derived from flatpak-spawn. My plan was to test it in Steam, and then contribute it (and other improvements) to flatpak-spawn when it's better-tested.

(Due credit: the pseudo-terminal juggling is derived from similar code in systemd.)

Allocates a pty for the spawned process, which fixes this issue; Passes through SIGWINCH signals, to handle terminal resizing

Those are implemented.

Passes through some env variables (such as TERM)

I'm unsure about this: it might be a good enhancement, but I'd want to provide a way to not do this, because if we unconditionally overwrite an environment variable that was inherited from the server (flatpak-session-helper or flatpak-portal), there's usually no good way to get it back.

[smcv]

Passes through some env variables (such as TERM)

I'm unsure about this

The way I ended up doing this for steam-runtime-launch-client is that it automatically passes through $TERM, but only if at least one of stdin, stdout or stderr is a terminal, and you can disable this with --inherit-env=TERM (part of a set of options for finer control of the environment, as mentioned in #28).

[1player]

Not a bad idea, though I'm not sure which programs benefit from not having $TERM set. AFAIK if you don't set it manually, it's not set on the host side, which often causes issues.

Looking forward to see your changes merged with flatpak-spawn. Do you have a standalone repo for steam-runtime-launch-client where I can play with it?

[sebastian-de]

My plan was to test it in Steam, and then contribute it (and other improvements) to flatpak-spawn when it's better-tested.

Hey @smcv, gentle ping on this - do you still have plans to upstream the mentioned changes? That would be much appreciated!