Not related to the speed, but is there any terminal for Linux that works like the Mac OSX terminal, in that you can shut it down and restart and it will bring up all the tabs and their cmd histories and scrollbacks for each tab? They do that by setting different bash history files for each tab etc.
This is pretty tangential, but I just (1 hour ago) found out that iterm2 on Mac can integrate with tmux [1] if you run tmux with the argument "-CC", in a way that makes your tmux sessions map to the GUI windows / tabs in iterm2, including when using tmux on a remote machine via ssh.
I'm really excited about this, since I always forgot the hotkeys/commands for controlling tmux.
> They do that by setting different bash history files for each tab etc.
I wonder what happens when you close all the tabs, and then open a new one. Are all the tabs history merged back into a "general" history file when you close them, so you will get access to its commands in new ones?
Yes, but if one process is writing its history to ~/.bash_history_1, and some time later you spawn a new shell whose history file points to ~/.bash_history_2, you won't have the commands from the previous session available, right?
Correct, but most of the time I use the same set of panes, created at startup, so the commands are in the history where I need them. And when they are not I grep in ~/.bash_history_*.
This. I was just looking for the exactly the same thing. For now I use tmux with tmux-ressurect to persist state between reboots. - It works okeyish, I would say it's a good hack but still a hack. It's sad there isn't really solution for this problem maybe aside for warp. My little UX dream is to have such a solution of saveing workspaces integrated with whole OS and apps inside it. - That would be cool.
I find it more preferable to setup bash (or whatever shell you are using) to append into .BASH_HISTORY file at every command. You don't always remember on which tab/pane/window you type which command and most people would do Ctrl + R or use a fuzzy search tool anyway.
Also many times you open a new tab/pane/window and would like to access the history of another one who is already busy running a job so a common history is usually preferrable.
At the time mac os got that functionality their macbooks had removeable batteries.
One fun fact: you could just remove the battery while your apps where running and when booting up again every window you had open would just reopen with everything you had typed saved to disk in case of the iwork apps.
While I fully believe this could work, seems like it might need to be a temp solution. Ripping out the battery seems like a solution that might have more downsides than advantages.
A lot depends on what are the important parts. It could be essentially identical if it supplies all the parts you care about and don't actually care too much what exact form it takes. But if you require the same exact gui controls then sure, totally different and not even an answer to the question.
And you have to get into tmux configs which is a hassle by itself. I am not a fan of terminal multiplexers, I tend to forget them and when the server crashes or reboot it won't replay/restart what I was doing in those tabs anyway. I just use them for long running jobs I am testing. I also don't like the whole tmux window/pane manipulation you can do, I'd rather have my primary DM to do that well.
It's funny how tmux is downvoted in those replies though :D.
How does it work in MacOS? Since some terminal commands are interactive (vim) and others have side effects (well, really, effects— rm won’t have the same result if you replay it!) I guess they can’t just be replaying/restarting programs, right?
Personally the only thing I really need is `mode-keys vi`, the rest is optional. I guess you want to configure mouse on/off depending on preference, if it differs from the default.
Usually will at least change the color of workstations and desktops just to make it more visually obvious which tmux environment I'm looking at when sshing and nesting.
It's C-b by default, C-a is what screen uses. Maybe you copied someone's config, as that remapping is fairly common (or weird distro default? but seems unlikely). I'm personally fine with the default C-b and have always kept it everywhere.
You can do the saving part automatically by setting a different history file automatically for each instance of the shell, for example using a timestamp on your rc file and force them to append after every command.
Then if you open a new shell and want history from a particular older shell you can do `history -r <filename>`
So it is an hybrid automatically saved, manually recovered mode.
Presuming my understanding of persistent sessions lines up with yours, set `terminal.integrated.enablePersistentSettings`. You may also want to change the value of `terminal.integrated.persistentSessionScrollback` to something higher than the default (1000? not sure)
It does for me when using a remote instance, like a devcontainer or over ssh. Maybe that is just because the server side keeps running and when you reconnect the UI reloads from there. Locally nothing would remain to be reloaded when you restart VSCode.
And I prefer GUI terminals for this use-case...