whisperity / monomux Goto Github PK
View Code? Open in Web Editor NEWMonophone Terminal Multiplexer - Less intrusive than tmux, smarter than screen
License: GNU General Public License v3.0
Monophone Terminal Multiplexer - Less intrusive than tmux, smarter than screen
License: GNU General Public License v3.0
monomux -i
Monomux handles ctrl+d elegantly (personally I would like monomux to just stop expecting any input and quit without any error code).
Monomux gets stuck in an infinite loop and keeps printing
Monomux sessions on '/run/user/1000/mnmx'...
1. Create a new session (/bin/fish)
2. Quit
Choose 1-2:
ERROR: Invalid input
E.g. in the interactive session selector, if the user just presses Return, the read keeps on reading from the next line which is visually unappealing.
We should support adding environment variables at session start-up and attach time to a list of obligatory injected variables that are stored for the session. (A good starting candidate for default of this list is TERM
, SSH_AUTH_SOCK
and COLORTERM
, but maybe even DISPLAY
.)
When attaching to a session, the newest attaching client must be queried about the values of these variables and the running session's environment should be set with these values. This part might require #11.
A lot of currently pending issues (#2, #5, #12, #14) will require changes to the communication protocol which would be backwards-incompatible. This would be the perfect moment to introduce, into the comms, a stable way of the server and the client discussing the versions of the protocol used. There should be a soft warning in case the server and the client are not the same binaries (string comparing Version::
whatever), and a hard error preventing communication if the API had breaking changes.
The API version should be versioned in a single global location in the code. A single unsigned number is enough... and we will hopefully keep updating it each time the communication layer changes.
An alternative solution would be creating a hash, at compile-time, from the most important and critical parts of the communication library. However, that would be too brittle and sensitive to refactoring changes in the source code itself that are irrelevant to the actual API at hand.
monomux -k
exit
the session auto-spawnedI need a shell integration that lets attaching monomux clients tell the session (and the shell within it) to change TERM
to the setting of the attaching client...
Seems like a moot and meek thing, but this could save an additional export TERM=
every time machines are changed. Although changing the TERM
of any already running but more complex process (e.g., neovim?) might bring issues and should just warrant a restart.
Also, this could be another "unsafe" flag (see #5) when two different clients (of different TERM
behind them...) want to attach to the same session.
There are several valid use cases in which the user's shell (inside a session) is not able to communicate directly with the server that is executing said session. The two most important of such are when the user su
s away (and no longer has write access to the socket) and when the session is running an SSH (or any other remote-ish) connection where the prompt the user can type in no longer has access to the socket. (In the latter case, even access to the monomux
binary might be unreliable.)
We should support some rudimentary keybind-based (e.g., screen's or tmux's C-a
) system where the user can bind a shortcut to a commonly used action.
Trivially implements #12 in practice.
Note: Idea taken from byobu.
A common problem occurs over elongated uses of Monomux where the user forwards the SSH Agent and starts a session with the environment in one forwarded connection (SSH_AUTH_SOCK=/tmp/sshd-..../agent
). When the connection terminates, the Agent socket is deleted, but the running session still points to it. The next connection just attaches to the session and tries to use the invalidated agent.
At least for the common case of SSH (luckily the Agent is a socket file that we can symlink and such...) we should create a path which we inject as SSH_AUTH_SOCK
into the spawned sessions. Every time a client attaches to the server successfully, we should ask the client what its SSH_AUTH_SOCK
is, and during the connection process, set the symlink to this path.
This way, the sessions will always see the latest attached client's SSH Agent, which might not be the best solution if multiple connections exist in parallel, but still somewhat better than only the first connection working...
It would be nice to open it in $HOME
or $PWD
directory.
Idea was taken from abduco
This could perhaps even be extended with the client at connection time finding all monomux processes and instructing them to recreate their socket BEFORE autoforking a server to the background, so the user does not have to manually send a signal at all.
With in-line detachment getting implemented as part of #3, it should be noted that there are cases when detaching from a running session is not safe to the client's terminal (due to us having no terminal emulation and no replay of display buffers...). Most notable of these is the Mouse events:
vim
(with a mouse-capable TERM
set) behind monomux
vim
2;64;18M2;64;18m2;99;27M0;99;27M2;99
Due to this, it is generally not recommended to detach without backgrounding a "full-fledged" terminal application (like vim
or mc
) first. Pre-#3, having to explicitly execute another binary sort of forced this behaviour from users. But nothing stops one client from attaching to an existing session where a feature application was running, in which case the new session did NOT receive the terminal state properly (and thus, e.g., mouse events were only happening from one session).
The server should be made capable of intercepting the output stream and understanding some control sequences mostly related to changing modes in the underlying terminal. With this, we could approximate what state the session is in, and be able to mark it as "unsafe". If the session is currently "unsafe", we should not let the user detach, and also show a warning when trying to attach.
Currently, if XDG_RUNTIME_DIR
is not set and TMPDIR
also is not set, the code immediately falls back to /tmp/mnmx
even though we could at least add the user's name into the file path anyway.
Moreover, it might be worth first to try to create also a directory in the temporary location (outside XDG_RUNTIME_DIR
, anyway), similarly to what tmux and abduco do.
I was poking around to see if I could script a session management around monomux and ran into this:
โฏ kitty +kitten icat 2022-08-18-130820_1025x812_scrot.png
Error: Terminal does not support reporting screen sizes in pixels, use a terminal such as kitty, WezTerm, Konsole, etc. that does.
Running this in the same terminal window but with monomux killed works.
Create a way to automatically execute bits 'n bobs of code at both session creation time, and at "sequence points" (such as prompt generations) within the session.
Support at least both Bash and Zsh.
Note: Envprobe already has this figured out. ๐
Instead of having to call the monomux
binary with a specific flag, the client itself should be able to send a request to detach, which would result in a graceful detachment (instead of a "kicked" message) of the client that sent the request.
Implementing this could also obsolete the -d
/--detach
flag. (Likely -D
/--detach-all
should be kept for scripting purposes.)
A
A
, create and attach to session B
B
, attach to session A
Both clients' and the server's CPU use will spike once it starts communicating data between the sessions recursively, resulting in a livelock of the affected sessions. On powerful enough systems, it seems that scheduling and queueing allow for other sessions to survive this ordeal.
Note: It is enough if session A
recursively attaches to session A
.
It is not trivial to detect and keep track of what session is attached to what other session, and while it could technically be possible, it is not worth the effort. A blanket denial of recursive Monomux attaches should be implemented instead. (This is how tmux
does it, by the way: "[...] sessions should be nested with care, unset TMUX
and try again [...]".)
This would actually be a detach (#3) followed by re-running the already existing session-attachment logic, but without restarting the server.
See contour-terminal/contour#687 for some general insights.
I'd like monomux to make use of the host writable status line. This is currently supported by recent(!) xterm as well as Contour.
You can detect support by the terminal using DECQRM.
Information I'd like to see (up to your imagination):
Given the last bullet point, it might make sense to be able to rename sessions (just like in tmux :D)
EDIT: forgot to mention: if anything is missing in Contour, please ping back to me.
Currently, all of the serialisation logic for the control message primitives are all built on top of hand-crafted code:
monomux/src/control/Message.cpp
Lines 224 to 340 in 6707ba0
While arguably this is the only part of the project that's actually tested, the logic behind the communication system follows a clear pattern, and there are not many data types that are generally transmitted (things are either strings, numbers, tuples, or an array of these...).
This means that the communication layer, the full serialisation logic, and perhaps even the automated tests for it (!) could be generated automatically from a sufficiently concise DSL. We should steer clear of heavyweight communication protocol libraries (such as Apache Thrift) or DSL parsers that depend on compiler-grade tooling (such as ODB implemented as a custom GCC frontend action) as such tools might make our compilation process too complex.
While this could be implemented as a fully backwards-compatible change, it might be worthwhile to do this together with (or as a precondition of) #17 and several other planned communication layer changes (e.g., #14). We might realise during making this that a different format is more suitable for comfortable automatically generated serialisation, and it would be great only to break ABI once if we can afford it.
#include <cstdint>
is missing in monomux/include/core/monomux/Log.hpp
https://gcc.gnu.org/gcc-13/porting_to.html
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.