Set current container: new escape sequence

This is about having an escape sequence to inform the terminal about the current container that a child process is running.

The use-case for this is primarily driven by OSTree-based operating systems like Fedora Silverblue.

On Silverblue, the OS (eg., the things shipped in /usr) is a read-only OSTree image. This includes just enough for a user to boot into a graphical environment - the kernel, the basic runtime, the D-Bus daemon, systemd, GVfs, GNOME Shell, etc.. Graphical applications are shipped as Flatpaks that are separate from the OS image, and are decoupled from the OS. This promises painless upgrades, clear separation between the OS and applications, and secure and cross-platform applications.

The OS doesn't come with DNF, and has a read-only RPM database. Instead, the OS is updated with ostree (and rpm-ostree).

For non-technical users, this is already great!

However, there's a problem if you're a hacker and decide to set up a development environment. You immediately run into the immutable OS image and the absence of DNF. You can’t install your favourite tools, editors and SDKs the way you’d normally do on a traditional GNU/Linux distribution.

This is solved by Toolbox. It lets you set up DNF-based mutable OCI containers which are separate from the OS, but still integrate seamlessly with it so that you can access $HOME, the Wayland and X servers, session and system D-Bus, GVfs, the GPU, SSH keys, Kerberos, etc.. So you can set up a development prefix as before, and use DNF to pull in your editors, tools and SDKs.

It's likely that hackers working inside a Toolbox environment would want to replicate the same environment when they open a new terminal from an existing one. Just like GNOME Terminal preserves the current working directory when opening a new terminal, it would be nice if it also spawned the same container so that the user doesn't have to type toolbox enter again and again. This aligns with the high-level goals of Toolbox - to reduce the cognitive burden of hacking on Silverblue.

If the terminal has enough information about the current container, just like it can know about the current working directory, it can automatically provide a shell in the right environment.

We are interested in making this work with GNOME Terminal and Toolbox as the immediate use-case. toolbox(1) would emit the escape sequence when invoking a shell inside a container, which will be interpreted by VTE and GNOME Terminal to track the container in use.

I am thinking of something like this:

OSC N; push; params; <container name>; <container runtime> ST
OSC N; pop; ; ; ST

The container name would be some unique identifier, and the container runtime would be one among a set of well-known keywords like docker, podman or toolbox. The runtime is necessary because one might not want the same behaviour for random Docker containers as they would for Toolbox containers, and would let the terminal implement some form of policy as to how it wants to handle things. eg., other than the aforementioned behaviour, the terminal could visually differentiate between different kinds of containers.

The container name and runtime could also be part of params, which is an extensible list of key=value assignments separated by a colon.

It's possible to invoke a shell running inside a different container while sitting at a prompt within another container, and hence the push / pop semantics.

I have no idea what the value of N should be, though.