What is Reddit's opinion of
tmux?
From 3.5 billion Reddit comments
91 reviews of this app found across Reddit:
The interesting part is why the default in systemd (i.e. whether or not to kill user processes) was changed in the first place. As per this comment, it seems to be because of some lingering processes from Gnome login sessions. The commit which actually makes the change doesn't cite any other reasons besides the generic "much cleaner and provides better control".
It is possible the actual reasons are sound and well-thought out, but the references provided by the person creating the issue fail to provide the sufficient rationale. It's not hard to understand the reluctance on the part of tmux's maintainers, especially given how much it's asked from them to accommodate for some other project's change which can very well be seen as frivolous.
It actually makes sense if you read the entire paragraph: > Alacritty is focused on simplicity and performance. The performance goal means it should be faster than any other terminal emulator available. The simplicity goal means that it doesn't have many features like tabs or scroll back as in other terminals. Instead, it is expected that users of Alacritty make use of a terminal multiplexer such as <code>tmux</code>.
https://www.reddit.com/r/linux/comments/4lh7yv/systemd_developer_asks_tmux_and_other_programs_to/
In short: when a user logs out, the new default behavior by logind is to bluntly "kill -9" all the processes that belong to that session instead of just sending a SIGHUP signal, which is the Unix/POSIX standard.
This solves the problem of lingering processes that don't clean up after themselves after you log out (i.e. Gnome), but it breaks widely used programs like screen, tmux and even the nohup command. So, you would start a screen/tmux session or a long running command with nohup, then you log out of your desktop or ssh session... and your screen/tmux session or long running command are unceremoniously killed by logind.
The reaction of the systemd developers was to suggest that tmux change their code, or that the user issues some kind of magic systemd incantation first, which is unacceptable to me. You don't just go around breaking long standing standards and then tell everyone else to change their code and scripts to adapt to you.
Luckily, this default behavior can be changed by a compile time setting and a configuration file directive, and most distros (including Arch) have had the sanity to ship with it disabled, but it sets a dangerous precedent and it demonstrates the "fuck everyone else" attitude of some systemd developers. They act as if they are working on a blank slate, creating their own OS the way they see fit as they go, but they're not. They are inserting themselves into a long existing OS with well established standards and traditions upon which millions of users are depending, and they should act appropriately.
edit: of course this gets downvoted immediately by systemd shills :)
tmux deals with this by waiting for x milliseconds - if another key is pressed within that time it is interpreted as <Alt-key> otherwise <Esc> then <key>
https://github.com/tmux/tmux/issues/131#issuecomment-145853211
Sure, one could define "not monolithic" and "modular" as having many different executable binaries that do many different things. That is not wrong per se, but the way the community use these terms is not specific enough, so these terms doesn't exactly convey the true meaning behind what they actually are.
Take a look at the Linux kernel. One can say that it has many modules so it must be modular and not monolithic. Except it is defined to be monolithic kernel (wiki article for details).
Systemd's case is a bit different. Sure it has these components, but its design assumes that all the bits must interface with it. Example: journald and binary log file formats. The other problem is that it also infects the entire userspace and manifests in other issues, such as systemd>=230 defaulting to a new unexpected behavior that kills user tasks when they log out, killing tmux/screen that they might otherwise run.
Seems innocuous enough when users can configure systemd so that it won't do this, however this is extra work to get a system to behave like how it was for the last few decades of *nix. On top of this, systemd developers escalated by trying to get tmux to adapt to their system, basically trying to get them to basically do add new code and dependency. This gives off the impression that systemd is a monolithic system that seeks to consume/absorb everything, showing how they run complete counter to the unix philosophy where they do one thing and one thing well. Forcing others to check for existence of their APIs is also not what interoperability is about, because instead of the original standard API, now there requires a special case for systemd.
They’re both maintained. I have no idea how you’re comparing them. They both are active. They both have recent commits.
Yes, they both have different feature sets, but that doesn’t mean that one is unmaintained.
If there’s a list of feature sets they wanted and the software is there, then it’s clearly just bug fixes and fixes when something breaks.
Clearly after 30+ years development will slow down if the features are there.
Screen is also included in a lot of default installations. Making big changes to it could break compatibility, builds and lots of automated things that rely on it.
It’s basically stable.
Here's one way I think you can do it with tmux:
- Open two terminals, one on each workspace of interest
- In one of the terminals, start a new tmux session with
tmux new -s <session_name> - Go to the other terminal and connect to the newly created session with
tmux a -t <session_name>
At this point, both of the terminals are "viewing" the same tmux session. This means whatever you do in one terminal will be seen on the other, and vice-versa. You can be on one workspace, start something running in the tmux session, do other stuff, and re-attach when you want to see how things are going. All the while, the other terminal will still be showing what's going on in the first session.
Not sure if this is exactly what you're looking for but I'd say dive in and learn tmux. You'll be glad you did. It is essentially like a window manager within your terminal that you can detach from and return to at any time so long as your system is running. There are some links to tutorials from here: https://github.com/tmux/tmux/wiki If you already are comfortable in i3, tmux should be relatively easy to learn.
You'll probably have better luck with your tmux questions if you ask them on the tmux subreddit: https://old.reddit.com/r/tmux/
Although, I'd recommend asking your question either on their bug tracker ( https://github.com/tmux/tmux/issues ) or mailing list ( https://groups.google.com/forum/#!forum/tmux-users ).
Yes - but the question still stands.
systemd likes to send SIGKILL to tmux too. The tmux guys (rightly) object to adding systemd-specific hacks to tmux.
And it seems pretty silly to run tmux just to keep one single process (gzip) alive.
Fair enough. If it's just to keep the session alive though, next time you need that see if you can use https://github.com/tmux/tmux/wiki or https://www.gnu.org/software/screen/manual/screen.html - most *nix systems will have them already and it takes maybe 2 minutes to learn enough to use them to keep a session open indefinitely.
Won't work for everything if you have things like enforced VPN timeouts, but handy for other stuff you need to leave unattended.
You should change the options to something like:
setw -g window-status-style none,bg="colour18",fg="colour7"
There's an argument with a decent explanation here: https://github.com/tmux/tmux/issues/1689
some terminal emulators have it built in...for example in konsole I can use <ctrl><shift><f> for search.
For something terminal emulator independent you can look into tmux. It has search in output
Here's the two I can quickly find from memory:
Lennart flexing that once kdbus is in the kernel (which it looks like it won't happen thankfully) his intention is to make it more difficult to maintain the eudev fork: https://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
Probably the most damning "gently push" statement: https://lists.freedesktop.org/archives/systemd-devel/2010-September/000391.html
If you sit around on the development lists for systemd you will quickly find more indications of this.
Another good one was when systemd devs approached the tmux devs and said effectively: "You know this feature we just broke on all systems, well actually it's your fault because we implemented a new feature and you didn't link your code against our library to tell us that you want the legacy behaviour."
Which promptly was laughed off of github by the tmux developers but it was another good indication of how the systemd developers want every excuse to integrate everything more tightly with systemd for no real good reason.
Here's a link for reference: https://github.com/tmux/tmux/issues/428
I had a similar issue in the past. To enable true color I've got the following in my tmux config:
set -ga terminal-overrides ",256col:Tc" set -g default-terminal "screen-256color"
And in my .vimrc:
if exists('+termguicolors') let &t_8f = "<Esc>[38;2;%lu;%lu;%lum" let &t_8b = "<Esc>[48;2;%lu;%lu;%lum" set termguicolors endif
Looks like I got this from here, but using screen-256color instead of tmux-256color: https://github.com/tmux/tmux/issues/1246
Font: lemon or any default console fonts (usually not loaded via fontconfig but can be found in the interwebs); Google and the Arch wiki will help.
Stats: lemonbar/conky or i3bar/i3status or just live without one (use dunst notifications for info when needed and rofi for window switching) (or keep a tty with tmux at hand all the time with some shell doing some stuff).
Launcher: rofi/dmenu (rofi also has a mode to "emulate" dmenu, and can use other extensions quite easily + the window mode is enough for me to live with no bars)
Terminal emulator: st/sakura/urxvt. Most other well-known emulators use VTE, which takes up quite a bit of resources. The lightest of the bunch are termite and Germinal (probably some other one too but IDK).
I'm assuming you need to spare as many resources as you can and that you know what you're doing, but don't overload the shell. Keep just what you need and strip the rest: no user@hostname if you won't SSH, no colors (okay maybe yes colors since we're in r/unixporn but you get the idea), etc.
Might want to look up tmux and learn to live with the CLI (i.e absolutely no X/Wayland, only CLI) if you want to taste proper unixporn.
PS. Rofi does not work on Wayland.
I think it was because of a bug in GNOME (what a surprise) where some GNOME stuff did not close when you logged off, so instead of fixing the bug in GNOME, systemd folks decided to instead fix it by forcing all processes launched in a session be SIGKILL'd when you log off, meaning stuff like tmux would have to have systemd-specific code in order to not get killed when daemonised.
On current master, mouse keys are available as regular keys, to be bound like any other – see commit bf635e7. However, this hasn’t yet made it into any release, so you’ll either have to build from source, wait until the next tmux release, or try to get it working in a different way (the commit message mentions “mouse-this” and “mouse-that”).
Afraid I still don't really understand the exact problem. konsole itself has nothing to do with the connection...so your problem probably is somewhere else.
You use telnet to start a shell on an external device? (And I see you can't use ssh :( ). In that case you could start a multiplexer like screen or tmux on the device...even if you have a short connection loss you can still reconnect to that multiplexer again to get the same shell session again. Question is of course if you can install tmux of screen on the device (or if one of them is already installed)
Tmux targets have this syntax
session:window.pane
So you should be able to pass the session name : your window name to the attach
Edit: here is the docs on what I am talking about. This is in the man page as well but here is the wiki https://github.com/tmux/tmux/wiki/Advanced-Use#command-targets
It looks like the error is coming from tmux's load-buffer - or save-buffer - commands, via the neovim clipboard provider. See https://github.com/neovim/neovim/blob/44c6deb91ac917703c157d564eb3accbff4d37af/runtime/autoload/provider/clipboard.vim#L104 and https://github.com/tmux/tmux/blob/ead6d652ffbf9870e6aaf5c40d3a8ceab7bb87eb/cmd-save-buffer.c#L72
It looks like tmux save-buffer - produces the "no buffers" error if tmux load-buffer - hasn't been executed at least once to create an initial buffer.
> Alternatives for home brew for Linux?
:-) Funny when you know that package management in Linux started somewhen in 1994/95.
Package management in Linux is first-class as compared to macOS where it is only second-class (first-class being the "macOS way").
As for terminals: You can choose from a variety of terminal application, Gnome Terminal being the standard one on Gnome and XFCE, konsole on KDE. But there are others like rxvt or the simple xterm. Regardless of the terminal I suggest using tmux (sudo apt install tmux) as terminal multiplexer if you're not using it yet.
Speaking of DEs (desktop environments): If you are familiar with macOS, you should probably start with Gnome since it is the DE most similar to macOS' appearance and usability (i.e. most things work out of the box, very few things can easily be customized, the rest needs special tools) and since Ubuntu 17.10 the standard for Ubuntu. If you want a very configurable desktop, use KDE/Plasma (and install Kubuntu, not Ubuntu), although it is a bit more heavyweight (I currently use KDE/Plasma).
If you need anything else, just ask - I'm using Linux since 2000 (with a short 2-year OS X interlude in 2008).
I suppose it depends on how strictly you define what is and isn't an OpenBSD project, but the base source code is centered around OpenBSD. A passage from https://github.com/tmux/tmux/blob/master/SYNCING :
* "tmux-openbsd" is the version of tmux in OpenBSD base system which provides the basis of the portable tmux version.
Since the OpenBSD version serves as the basis for all others, I still don't think "even" applies here.
Yap, welcome to the tribalism. They refuse to support it essentially purely by association. These are the mentalities of the people that make our software and run our world. People who make decisions purely by tribalism and association.
It's essentially their own little version of "Hitler popularized child support, therefore child support is bad"
Note that on my system ~/.tmux.confis a symlink to ~/.config/tmux.conf. Putting all configuration in a single directory is simply put a very good idea rather than putting it in your home dir. And a proper respect of the standard just allows you to set XDG_CONFIG_HOME=$HOME to move it back there if you want. (The standard doesn't specify whether you should then put a dot in front of it and some things actually don't which is stupid)
Edit: https://github.com/tmux/tmux/issues/142
Jesus Christ, these guys are in every single fucking way just as bad as Freedesktop here. This is such a fine example of how often two extremist camps who hate each other have way too much in common. It's like watching fundamentalist Muslims and Christians hate each other while agreeing on 99% of shit.
The others already pretty much stated it.
See what Australian_Accent said in the past about systemd:
>Isn't the Unix philosophy wonderful? I now get to choose what I want to use to administrate cgroups while systemd users are at the mercy of what Lennart decided for them what is best.
With Void, I get to choose what I use to adminster cgroups (if I wanted them). I get to choose what to use to handle acpi events (so I can set myself to Away on hexchat, lower the screen brightness, etc. when the lid closes). I get to choose what system logger I want. I'm not at the mercy of anyone else deciding what is best for me.
From here: >My concern is that we have a little function, daemon(), that does a simple little procedure to make a daemon that has worked basically unchanged across multiple platforms for maybe, what, 30 years? Now to do the same thing we need to add 150 lines of new, Linux-only code AND a library dependency.
It's breaking 30 year old standards to clean up after GNOME. That's not a good thing in my opinion. Shouldn't break stuff that works just because GNOME can't clean up after itself.
I didn't say it was a perfect analogy, just the best one I could come up with. That only applies to someone who's actually a programmer or who can hire a programmer. Otherwise, having the source code is pretty much useless. And even then, you're acting like the cost to fork is zero. "Just fork!" The cost is definitely not zero. I'm not saying systemd should cater to me. I'm just saying systemd violates UNIX philosophy and that makes it bad software. There's a reason why UNIX philosophy exists, and it's not just freedom, although that's part of it. There are practical benefits to "do one thing and do it well." But meh. I think I'm wasting my time so I'll leave it at that.
Let's put what I'm saying in another manner. Systemd would be a great piece of software if it was decouplable. Let's leave it at that. This is what someone on Slashdot had to say about systemd not being decouplable:
>If the people behind systemd had any actual Unix-development skills, that is exactly what they would have done. Instead we have a monster that tries to assimilate everything. Huge egos often coincide with small skills. This is a nice example.
But now I understand why lennartwarez rants like she does.
https://www.reddit.com/r/linux/comments/4poxkv/join_the_public_beta_for_suse_linux_enterprise_12/d4ms5wx
I'm also just going to leave this here.
https://www.reddit.com/r/linux/comments/4kh6jv/systemd_v230_released_features_including_dnssec/d3f2l1h
"My concern is that we have a little function, daemon(), that does a simple little procedure to make a daemon that has worked basically unchanged across multiple platforms for maybe, what, 30 years? Now to do the same thing we need to add 150 lines of new, Linux-only code AND a library dependency."
^ That is what happens when you let Lennart be the sole arbitrator of what is best on your system.
tmuxline applies vim color scheme to tmux status, neovim colors depends of your $TERM
You can also try the tmux with truecolor patch (tmux-24bit-color on AUR), you can see also https://gist.github.com/XVilka/8346728
Boa sorte
I guess I'm using it like you would use screen, split screen and organize stuff, but it has a few extra features that really make it shine: - you can have different sessions, then windows, then panes. The session level is pretty nice to have - you can actually ssh into a session > remote working - plugins. (A lot) fewer than vim, but they make your life so much easier
I'm probably missing a bunch of things, and as I've never used screen, the difference might not be that big.
Anyway, you should check it out to see if it's worth a try for you: https://github.com/tmux/tmux/
I don't think you should copy the value data into your list data structures, but rather let the user of your library control what happens with the memory.
If you think this is too inflexible, have a look at the way OpenBSD solved it for red-black trees (I'm linking the tmux compat layer here, because it is simpler to point out the relevant parts, it is the same as in the OpenBSD source tree): in tree.h:
#define RB_HEAD(name, type) \ struct name { \ struct type rbh_root; / root of the tree */ \ }
#define RB_ENTRY(type) \ struct { \ struct type rbe_left; / left element / \ struct type *rbe_right; / right element / \ struct type *rbe_parent; / parent element / \ int rbe_color; / node color */ \ }
and in tmux.h:
struct environ_entry { char *name; char *value;
RB_ENTRY(environ_entry) entry; }; RB_HEAD(environ, environ_entry);
As you see, the macros are inserted into a user supplied data structure and therefore let the user have full control about the usage. The data could now be stored inline:
#define DELTA_STRING_LIST_CHUNK_SIZE 1024 struct DeltaStringList { size_t length; char value[DELTA_STRING_LIST_CHUNK_SIZE];
DELTA_LIST_ENTRY(DeltaStringList) entry; };
or in a separate string table or the likes somewhere else:
struct DeltaStringList { char *value; DELTA_LIST_ENTRY(DeltaStringList) entry; };
its not being consistently 20ms faster/slower, but it adds like half-a-second lags here and there.. its not about "being slow" anymore, i'd say its a bug...
its like having a slow, but consistent internet connection v.s. an unstable internet connection that spikes and drops randomly. The former is mildly inconvenient, but you can learn to live with it, the latter will drive you mad..
when you're using vim, chances are you like the snappiness of it, but using vim inside tmux on macos, thats completely negated. even just scrolling around files feels miserable, things like auto-completion/fuzzy finders is pretty much unusable...
The quick and nasty way before you automate it all is to use something like tmux (https://github.com/tmux/tmux) which is available on most distro's. It will allow you to start a terminal session and run it in the background so it won't matter if you get disconnected you can always reconnect and re-attach to the session.
I'm using sakura for my terminal: it's lightweight, and neat. But really, tmux is the star here; it really takes the terminal into another region of excellence, power, and functionality. I now couldn't live with tmux.
For editors: GNU Emacs. I don't want to start an editor war here, but I always have an Emacs windows open so I can simply edit things on the fly as I need to. And some of its plusses for me are its support for LaTeX (auctex package); TRAMP for editing external files: I can SSH into my VPS from Emacs and edit those files as though they were local; org mode and various extras like org-reveal (for creating web-based presentations with reveal-js), export to HTML, and so on. To those people who see Emacs as a bloated system, you're probably right, but in these days of lots of RAM it's less of an issue than once it was. A few years ago I spent six months making a concerted effort to learn vim properly; I went cold-turkey on Emacs for that time. Regretfully though, the experiment was a failure; my use of Emacs is too in-grained to change.
Vivaldi for web browsers - and with its new in-built mail system!
Dolphin for file management (but more often I'm just in the terminal). Sometimes I use Ranger to explore subdirectories.
Zathura for PDF viewing.
Spectacle (KDE) for screenshots.
Syncthing for syncing files. I used to deploy Nextcloud on my VPS, until I stuffed it with a failed upgrade.
calc: a command line calculator with arbitrary precision. GNU bc is good too, but calc has more built-in commands (combinatorial, number theory functions for example). You can use it interactively, or simply to provide the results of a calculation. Try this: in your terminal, enter
calc "factor(2^67-1)"
feh for viewing images in a directory. The best quick image viewer I've found.
it actually does waaaay more than allowing terminal window splitting and/or rearrangement.
​
it allows running multiple sessions and can keep each or all in the background, then you can open them instantaneously and continue working on what you were working on.
​
imagine you have an IDE and you manage multiple projects. each project has a configuration and the IDE remembers all open files for each project, all linter configurations and whatnot, and opens each project with its open files and configuration.
that's my take at ELI5.
​
Depending on your context, switching to direnv + scripts in a project-local bin directory might make your aliases shareable with other members of your team, which may be useful.
Given your description of switching between projects, you may also be interested in tmux, which I've also written a blog about.
Personally, I really like the super wide screen with tmux for coding.
It's great to have two (virtual) screens side-by-side so you can be referencing a manual or example code while keeping your project open.
Though I agree that without doing some kind of multi-tab thing it's harder to read a single wide line.
I'm currently prototyping a little pi laptop/cyberdeck using one of these screens and a planck keyboard. Very excited.
Add this to your $HOME/.tmux.conf
bind -n MouseDown3Pane send-keys -M MouseDown3Pane
I tried with unbind first, but it didn't work.
The bind should be replacing the default bind from https://github.com/tmux/tmux/blob/master/key-bindings.c#L471 and it should send the mouse event to the pane.
Hope it works
- Lets you start a program that normally ties up the terminal window and detach it so you can close/reuse the window while it keeps running in the background
- Lets you scroll up to see output you missed in virtual terminals
- Can split windows into different sections (split the screen to create another terminal window to the right or below)
- Can create multiple windows in a session and multiple sessions
Some things I find handy:
- Lets you start a program that normally ties up the terminal window and detach it so you can reuse the window while it keeps running in the background
- Lets you scroll up to see output you missed in virtual terminal windows
- Can split windows into different sections (split the screen to create another terminal window to the right or below)
- Can create multiple windows in a session and multiple sessions
Example of how you can use it:
When I used Tumbleweed, sometimes big updates would cause the desktop environment to freeze, so they are best run in a virtual terminal. So would CTRL-ALT-F1 to go to a virtual terminal, start a tmux session, start the update, and CTRL-ALT-F7 to return to the desktop.
From the desktop I could keep an eye on the update progress without switching back to the virtual terminal by opening a terminal window and attach to the tmux session that is running in the virtual terminal. Then I would see exactly what was happening on the "other side".
I'm not sure this would be exactly what you're looking for in terms of a shortcut for running multiple commands across multiple terminals, but you may want to take a look at tmux: https://github.com/tmux/tmux/wiki
Because C-Num isn't a valid key in old school terminals and so tmux which tries to support as many terminals as possible doesn't have something that only works in a subset of them enabled by default. If your terminal emulator supports it u can configure tmux to accept these keybindings https://github.com/tmux/tmux/wiki/Modifier-Keys
You can follow the instructions to build from release tarball: https://github.com/tmux/tmux/wiki/Installing#from-source-tarball There is already a release for 3.2, so you don’t need to build from version control.
You can use tree mode (C-b w) then tag windows with t and kill all the ones you have tagged with X (S-x). Look at https://github.com/tmux/tmux/wiki/Getting-Started#choosing-sessions-windows-and-panes.
https://github.com/tmux/tmux/issues/1391#issuecomment-402428189
Since you are building this from the ground up, you could probably decouple the rendering portion to support different pixels/cells for sessions simultaneously attached to the different terminals. Maybe you could make an interface or api for other terminals to use, and offload that work to the terminal emulator authors.
Just some ideas.
But it does seem like an advantage you have over maintainers of an old codebase like tmux/screen/etc.
If you just want to open a new window/pane to display the output of some script, I don't think send-keys is what you want.
I vaguely remember reading about piping to something like tmux new-window in the docs or the wiki that seems to do what you want.
I tried to track it down, but couldn't find it. Closest I came across was pipe-pane, which I don't think is exactly what you want, but you may find it helpful: https://github.com/tmux/tmux/wiki/Advanced-Use#piping-pane-changes
Boo. Though, someone has a fork where they've managed to customise the borders: https://github.com/tmux/tmux/pull/1785
Also, maybe it's just the issues I've looked at, but I find it slightly amusing that nicm's typical reaction to a feature request is "no, sorry, not interested." And yet shortly (or perhaps not so shortly) after, he comes back to say "here's a bunch of work I've put into trying to implement your request".
https://github.com/tmux/tmux/wiki/Clipboard confuses me. Is there some sane configuration I should be using because the defaults with https://github.com/kaihendry/dotfiles/blob/master/.tmux.conf do not work for me. :(
if-shell syntax
if-shell -F (condition) {execute this block if true} {execute this block if false}
M-f mapping
condition:
#{==:#{session_name},floating} (current_session_name == floating)
if true:
detach-client (you will be in floating window, so detach from that.. close popup and back to orig)
if false:
set -gF '@last_session_name' '#S' (set global variable last_session_name) popup -d '#{pane_current_path}' -xC -yC -w70% -h70% -KER 'tmux new -A -s floating' (start popup window)
! mapping
condition:
#{==:#{session_name},floating} (current_session_name == floating)
if true:
break-pane (break out the current pane into a new window)
if false:
tmux break-pane -s floating -t $(tmux show -gvq '@last_session_name'): (get the pane from session named floating "floating" and put it in the session in the var last_session_name)
@ mapping
>Same as ! mapping, just that focus does not shift to the broken pane after it moves to new window
Also checkout tmux wiki as he suggested.
I am looking at the Flask-APScheduler examples and it appears that you can schedule tasks from Flask itself, yes? So you should be able to just run your Flask App as a service.
If that is not something you are able to do, you may enjoy tmux.
- SSH into the server
- run
tmuxthen run your process there - If your process is not daemonized, type
Ctrl-zthen runbg - Don't exit! Instead, type
Ctrl-bthend - Exit
- SSH again (sooner, later, it doesn't matter)
tmux a("a" is for "attach")- Prosper
Try installing a program on your server called "tmux".
This will allow the program your are running to keep running if your connection fails for some reason. It also alpaca you to run multiple shells within the same session.
You can reconnect and attach to your session if your session hangs or is disconnected.
Right but these tell me nothing. Where did you copy from? What are you expecting to see?
Did you copy this text from vi? I already explained that text copied from vi will contain extra newlines because tmux has no way to distinguish newlines in the original text from newlines or cursor movement used by vi.
I don't really have any more time for this endless round of partial information from you. If you can come with a sensible set of steps that will allow me to reproduce what you think is a genuine problem then please open an issue at https://github.com/tmux/tmux/issues and I will investigate at that point.
In 3.1, yes. So this depends on the version you are using.
-l 70% should work with later (>=3.1) version though if my understanding of the changelog is correct.
https://github.com/tmux/tmux/blob/91e40de2da5124b1593c1c25462b8c9a36b8ebfd/CHANGES#L315-L317
> https://github.com/tmux/tmux/issues/34#issuecomment-241527745
I think this issue has the opposite problem I have where true colors work outside of tmux but not inside of tmux. Is that correct?
I'm having an issue where my vim colorscheme works inside of tmux but not outside of tmux.
https://github.com/tmux/tmux/issues/34#issuecomment-241527745
> @gfairchild Try removing the default-terminal setting from your tmux config: > > set -g default-terminal "xterm-256color" > And only set terminal-overrides to reflect your actual $TERM outside of tmux: > > set-option -ga terminal-overrides ",xterm-256color:Tc"
Could just switch into raw mode and use raw ansi escape codes. tput should allow a lot of that without dropping into C. By switching between the default and alternate buffers you can double buffer to fix screen tearing too.
After some research, this apparently is a long standing issue with reflow in tmux See, e.g.," " https://github.com/tmux/tmux/issues/516" (or if this is not the same issue it describes my problem). just discovered a workaround when using Windows Putty. In Putty, edit your settings by ticking on "Disable remote-controlled terminal resizing" in Terminal->Features. Resizing in Tmux then works perfectly (at least for me) YMMV
I ended up with OSC-52 inspired by tmux:
printf "\033]52;c;$(echo "FOO" | base64)\a"
But this does not work outside hterm, the default terminal emulator of Crostini.
My man, are you talking about this?
And yeah even though this sub isn't as chatty as others I really do appreciate all the maintainers and contributors.
Write some code that calls sysctl(2) {CTL_KERN, KERN_PROC_CWD, pid}. This perl seems to work:
#!/usr/bin/perl use v5.12; use constant { SYS_sysctl => 202, # <sys/syscall.h> CTL_KERN => 1, # <sys/sysctl.h> KERN_PROC_CWD => 78, PATH_MAX => 1024, # <sys/syslimits.h> }; my $name = pack('iii', CTL_KERN, KERN_PROC_CWD, shift); my $buf = "\0" x PATH_MAX; my $len = pack('l!', length($buf)); syscall(SYS_sysctl, $name, 3, $buf, $len, undef, 0) == -1 and die "$!\n"; say unpack('Z*', $buf);
Usage: perl cwdof $pid
For other operating systems, check osdep_get_cwd() in the osdep-*.c files of portable tmux.
How are you configuring your colours? There are two things that could be happening:
tmux starts login shells by default, are you sure you have this configured for login shells?
GNU ls famously has a whitelist of
TERMvalues and tmux may not be among them, does it work if you dols --colors=always? What if you setLS_COLORSyourself?Are you using RGB colour? Are you sure tmux knows that the alacritty supports it? Do you have
TERMset toalacrittyoutside tmux? Or see https://github.com/tmux/tmux/wiki/FAQ#how-do-i-use-rgb-colour.
This is what I meant when I said command-line tools, though I admit I don't know what hex or mix are. Tmux also expects the configuration file to be in the home directory, and somewhat annoyingly refuses to support XDG.
https://github.com/tmux/tmux/issues/142
Interestingly, I did just discover that git does support XDG base directories. I hadn't known that.
Some other modern tools I have dotfiles for in my home directory:
- .clang-format (c/c++ formatting tool)
- .keras (Google's tensorflow)
- .pulse-cookie (this is ironic given one of the authors on the XDG Base Directory Specification)
And there are a ton of older software that also have files/directories there such as gphoto, gnupg, less, octave, python, units, and X. I also have dotfiles for some proprietary software, but I have no expectation those will ever be fixed.
If you're insistent on running Eclipse specifically, there's really nothing I can say that's going to help you. Because, unfortunately, Eclipse is a pretty demanding program to run - it's been around for almost 19 years so it's no wonder it's received a lot of cool features, but that's made it a bit heavy. Honestly, even there was an ARM package for it, it's nothing I'd try to run on any less than a recent flagship phone. But...
There's plenty of editors that work in text mode that you can run directly on your Linux machine in a shell that you've started in mosh - some of them, like emacs, can be configured as full-fledged IDEs. And compiling inside an IDE almost always is done by triggering the external compiler or build tool, so all you'd have to do is find out what the command is. (I don't see anywhere you've mentioned what languages you're programming in, and modern Eclipse supports a lot of them.) If you don't want to spend the time to configure a text-mode IDE, you can add either screen or tmux to your tools and not even have to shut down your editor to do your compiling. (Both of those tools should be in your distros repositories, so there should no difficulties in setting them up.)
I have been working on adding additional documentation beyond the man page which by nature can be quite daunting (it had to mention everything and had to use a particular structure).
https://github.com/tmux/tmux/wiki/Getting-Started - aiming to cover the common features for interactive use
https://github.com/tmux/tmux/wiki - this will cover more advanced features and scripting but it is currently unfinished
https://github.com/tmux/tmux/wiki/Formats - format syntax
These are relatively new and will be improved over time.
You might be interested in [tmux](https://github.com/tmux/tmux/wiki) as well. It's a great tool to boost productivity.
You'll see most experienced Unix people have very customised WMs, terminal multiplexers, and text editors. The reason for this is that these kinds of tools allow a level of flexibility and customisation that simply isn't designed into other 'use-out-of-the-box' tools (the question of DE vs WM really boils down to this).
There is a big up-front investment of time that is put into learning and customising these tools but the dividends they pay down the road (factors such as productivity and convenience) are massive.
I think tmux has a hardcoded set of keys that it allows:
https://github.com/tmux/tmux/blob/master/key-string.c
I think you need to add them to that key table, and recompile your tmux with the modified code.
- Wallpaper: #2E3436
- Other: Hooked into the server via ssh, using tmux to create workflow.
We were throwing out an old server at work, I asked if I could bring it home instead and they agreed. Brought it home, vacuumed out the dust, and installed Debian on it.
Regarding (1), you can hold Shift to circumvent tmux's mouse handling (this also works with other terminal apps using the mouse) and still do click-and-drag to select text. Line breaks are not always detected correctly though, see https://github.com/tmux/tmux/issues/530.
I end up using that most of the time (along with my Ctrl-Shift-c/v terminal shortcuts, or middle-click pasting), though I also have https://github.com/tmux-plugins/tmux-yank installed which adds a prefix + y shortcut to copy to the system clipboard from tmux's copy-mode.
I also use Vim where I have mapped Ctrl-c/v to use the system clipboard as well.
The lag is due to how terminals work with Escape. Set escape-time: https://github.com/tmux/tmux/wiki/FAQ#what-is-the-escape-time-option-is-zero-a-good-value
Meta key is sent to tmux by the terminal by prefixing with the Escape character (\033), by default in X this is Alt, you shouldn't need to configure xterm for this to work. If you map CapsLock to Escape it is not necessarily the same when you hold keys down together. You may want to map it to the Meta (or Alt, I forget what X calls it) modifier instead if you want it to behave like a modifier instead of the Escape key.
There's already a request in the GitHub repository, but it's currently not a high priority topic since almost every modern terminal is able to provide _true colors_. Even if not, running a shell session through tmux will allow to use Nord tmux for a better experience.
Anyway, if someone really depends on 256-color support a PR might be a good start since unfortunately my free time to spend for OSS projects tends towards 0 due to real life tasks.
Yep, vim was always installed on servers I was working on; emacs less so. +1 on tmux as well.
mosh, tmux (with tmuxinator), and vim are my jam. Investing time learning these tools has been a huge boost to my workflow. There is nothing better than sitting down for some remote work, firing up a pre-configured session with various windows logged in to several servers and commands auto executed. With mosh I can then close my laptop for a bit or even travel to a new network and pickup right where I left off without having to reconfigure/relaunch anything.
> What I want to achive is to create a tmux binary from the sourcecode that uses that config from a greater version.
Just build tmux yourself and use it. Here is the repo: https://github.com/tmux/tmux
You can do pretty much anything you can think of really. QMK has a really expressive API for macros, and you can run them on each click of the rotary so you could probably even have it doing different things on each click, but that sounds like an absolute nightmare! I have mine doing different things on three layers.
Standard: volume controls, and the click does play/pause Raise: cycles through tmux panes, click detaches the current session Lower: cycles through tmux windows, click detaches
I basically live in tmux sessions at work and a lot of the shortcuts I use all day are kinda claw-ish. I thought the rotary would either work great or be fun but ultimately less productive. I've actually found it to be far better for navigating tmux sessions. Probably not worth adding a 4th layer for something else though!
Yes, you have buffers, tabs and windows, this response in stackoverflow explains a good approach to use:
Why do Vim experts prefer buffers over tabs
Another option is to use Tmux .
Since version 1.7, tmux supports the bracketed paste mode, but it doesn't use it by default.
In the key bindings table, ] is bound to paste-buffer:
bind-key -T prefix ] paste-buffer
If you want paste bracket control codes to be inserted around the buffer, you need to pass the -p flag to paste-buffer.
FWIW, I use it in these 3 key bindings:
bind C-p paste-buffer -p bind p choose-buffer -Z -F "#{buffer_sample}" "paste-buffer -p -b '%%'" bind -T copy-mode-vi p send -X copy-selection-and-cancel \; paste-buffer -p \; delete-buffer
If you use bash, I think you need a version greater than 4.4, and a readline version greater than 7.
You also need to set the readline variable enable-bracketed-paste to on in ~/.inputrc:
set enable-bracketed-paste on
If you use zsh, you need a version greater than 5.1, and make sure that that the zle_bracketed_paste parameter is set. You can check its current value by running $ typeset zle_bracketed_paste, the output should look like this:
$ typeset zle_bracketed_paste zle_bracketed_paste=( $'\C-[[?2004h' $'\C-[[?2004l' )
> this is more likely to do with it being resized when attached
I could very well be wrong, but I don't think this is the case. I believe the issue is because of the following:
> Detached new sessions are now always 80x24.
Thanks for the suggestion, though. I'll do some experimentation when I get a chance and follow up.
I'm a huge advocate of tmux. It's high energy to start, but entirely customizable and so bonkers powerful that it makes window management optional. I refuse to work without access to the combination of tmux and vim.
https://github.com/tmux/tmux/blob/master/grid.c
This is the part for storing screen history and scrollback. It is quite a readable solution. Both the screen and state of the screen are recorded into a "grid" data structure and scrolling simply allocates/deallocates new lines in the screen. A history limit is kept for reasonable reduction in complexity.
> because I've never really been a fan of X
There might some good X-based solutions depending on what you mean by X when you say you aren't a fan.
I can think of a few things you mean by not being a fan of X:
- Liking fixed-width fonts
- Not liking a cursor
- Not liking unnecessary display tools
- Liking having keybindings everywhere
I might go for startx $(which gnome-terminal) -c "tmux" as a good starting point - it looks like tmux can be coaxed to supporting 24-bit colors https://github.com/tmux/tmux/pull/112
I imagine there might be better support for this than for framebuffers.
To further help you, here's my <code>i3/config</code>, and here's the script that I use to start all my scratchpad programs (it also kills and restarts the ones that already exist). I use tmux, so I can kill my terminals without any issues.
Yes she does.
She's referring to the fact that the tmux developers refuse to support having the tmux configuration file under ~/.config (or whatever one might have set their $XDG_CONFIG_HOME to).
Links:
> Tmux's documentation consistently refers to this key as the "prefix." There is no need to invent a new and potentially confusing name for it.
Good point. Don't want to get confused with vim. Thank you for that.
> The available hooks are listed in the tmux manpage, under the section header "HOOKS."
(Speaking in terms of tmux 2.6's manpages, I'm not using master on any machines ATM:)
Unfortunately, not all of them are explicitly listed. Enough to confuse myself and at least one other person (in the comment after, I actually dig into the code of where the hooks are triggered).
One of the issues I have with updating tmuxp for tmux 2.6's changes was the hook being triggered. It wasn't apparent or obvious to me when certain after- commands didn't fire.
I don't remember what it was specifically, but I think it was after-switch-client not firing with the switch-client command, but client-session-changed instead.
Actually figured it out after reading through the whole release notes. Funny what you will figure out just after posting. I'll leave this up in case other people run into this issue.
They aliased bind-key s to choose-tree instead of choose-session you just need to put it back
bind-key s choose-session
Assuming you want to be able to connect back and check up on it, you should look into Tmux, which lets you start up a shell session, disconnect and leave the session running in the background, and then reconnect to it later.
For me the only problem was root bindings not working in copy-mode-vi. Obviously it can be easily worked around duplicating each normal bind with -T copy-mode-vi (but is ugly and all).
It seems it has been solved https://github.com/tmux/tmux/issues/881 but the fix is not released yet.
Are you aware of this
What can you do as an admin if tmux decides to automatically and internally do what systemd is suggesting here to avoid being killed on logout?
This is the function "bar" i was talking about. How is this different from calling function "foo" that internally traps SIGHUP? They both lead to the same result,the application surviving logout.
I use the following and mousing works fine in El Cap.
# Allow mousing set -g mouse-utf8 on set -g mouse on
# Return pre-2.1 mousing behaviour # https://github.com/tmux/tmux/issues/145 bind -n WheelUpPane if-shell -F -t = "#{mouse_any_flag}" "send-keys -M" "if -Ft= '#{pane_in_mode}' 'send-keys -M' 'select-pane -t=; copy-mode -e; send-keys -M'" bind -n WheelDownPane select-pane -t= \; send-keys -M
Full .tmux.config.
I also had exact the same error when trying to statically build tmux 2.0 & 2.1. I guessed there must be some changes in the configure.ac that led to the problem. What I did was to compare the configure.ac, Makefile, etc.. and finally I figured it out. This error was due to the libutempter introduced in the development of tmux 2.0 in the commit https://github.com/tmux/tmux/commit/4273c1b80e2eb321d44154fe1e82e0f11aabcbd5. You system should have a utempter-0.x.x installed, and "configure" will find utempter available. However, there is a libutempter which is another utempter implementation sort of. And the utempter-0.x.x available in your system is not the libutempter expected by tmux 2.0 & 2.1.
First of all I had to build libutempter in /root/workspace/libutempter-1.1.6, and used the below commands to statically build:
./configure --enable-static CFLAGS="-I/tmp/local/include -I/tmp/local/include/ncurses -I/root/workspace/libutempter-1.1.6" LDFLAGS="-L/tmp/local/lib -L/tmp/local/include -L/tmp/local/include/ncurses -L/root/workspace/libutempter-1.1.6" LIBEVENT_CFLAGS="-I/tmp/local/include" LIBEVENT_LIBS="-L/tmp/local/lib -levent"
According to this comment (https://github.com/tmux/tmux/issues/108#issuecomment-148160119), the tmux head 2.1 didn't solve this problem (since it's an apple bug instead of tmux), it just makes the bug happen less frequently.
compile it from source. it's easy once you learn the dance:
if ! grep 'deb-src' /etc/apt/sources.list; then echo 'deb-src http://http.debian.net/debian main' | sudo tee -a /etc/apt/sources.list && sudo apt-get update; fi sudo apt-get install build-essential checkinstall autotools sudo apt-get build-dep tmux mkdir ~/build && cd ~/build git clone https://github.com/tmux/tmux cd tmux ./autogen.sh && ./configure && make && sudo checkinstall tmux -V
this off the top of my head, but i'm fairly confident it should work
If you depend on Tmux (Terminal Multiplexer), then it's best to stay cautious of upgrade because of: https://github.com/tmux/tmux/issues/108
I've been seeing this problem since upgrading to Public Beta, up till (and including) the GM release.
Except for this, pretty decent upgrade.