Repository navigation
Restore previously closed session's state (Buffer contents) #961
Description
Lets talk about restoring the state of the terminal here.
This could arise in two scenarios I'm thinking of:
- Restoring the state of a previously closed terminal session (i.e. the app was closed due to a restart, and you launch it again)
- Restoring from a previously closed tab in this session (i.e. you've closed a tab, but not the app.)
1 is certainly harder than 2.
Restoring the buffer contents wouldn't be impossible, but restoring the actual state of the running executable might be impossible. IIRC Malcolm Smith (@malxau) has a long email from his work on yori that is relevant to this discussion.
We could certainly restore the buffer contents from file, then display some sort of message saying [Restored from previous session]. That's not that hard.
Reacted by Benjamin Staneck, Thecentury, ^_^, Oleg Matrozov, Ahmadali Shafiee, Stefan Ilic, Igor Kustov, Pavel Anikhouski, Jannik Buschke, Alex Kondratiuk and 168 more
Reacted by brianoc, Dany Gee, axadkrk, Bart Plasmeijer, Adam Marks, Suvidh, Dieter Oberkofler, Vladimir Chebotarev, Brian Heilig, sommelon and 31 more
Reacted by Jonas Sandstedt, frederikhors, Anner J. Bonilla, scPmYGit, Juan C. Andreu, R F, wrkntwrkn, Juraj Mäsiar, Tim Maffett, cryodream and 2 more
Activity
binarycrusader commentedon May 24, 2019
I think there are possible security considerations with this. With that in mind, making restoring previous output seems an opt-in rather than opt-out feature seems prudent. On Windows of course if the user's profile is BitLocker-protected, maybe it's less of an issue, but regardless worth considering.
I did enjoy this feature of Terminal.app for the few years I used a mac some time ago.
malxau commentedon May 24, 2019
Firstly, welcome to github and the terminal project, @BEAClerbois!
Just adding to the record some of the information Mike Griese (@zadjii-msft) is referring to, I tried to implement save/restore of state as part of Yori, which is a CMD-like shell. This was opt-in due to the security/privacy issue that Shawn Walker-Salas (@binarycrusader) mentioned, and is enabled with an environment variable. See http://www.malsmith.net/yori/guide/#env_yoriautorestart .
In that context, save/restore meant saving both terminal state as well as shell state. Terminal state includes things like the size and position of the window, its contents, colors, and fonts.
Shell state includes things like current directory, environment, and in this case, aliases and command history.
But the real challenge is how to reason about multi-process relationships. One example was given previously: suppose the user launches a CMD window, and within that launches Powershell. Even if both
CMD and Powershell were capable of saving their state, the restoration process needs to include a) terminal state; b) a CMD process with its state; c) a Powershell process with its state; d) somehow get the CMD process to wait for the Powershell process to terminate. (d) is very unnatural because on the running system the parent can only reason about the child via a handle or PID, and here neither are known until the child is running. It's possible that I'm not thinking creatively enough, but this sounds a bit like a cyclic dependency, because on the one hand the parent process should be fully restored before the child can accept user input and terminate itself, but on the other hand, the parent process can't really know what to wait for until the child is present.
A clearer example of the same effect would be opening CMD and within that executing "vim foo". The terminal will know about the existence of the vim process, but the meaning of "foo" depends on the current directory that vim was launched from, and that information has to come either from vim or from the parent process, and CMD needs to wait for vim. Recovering things accurately would require coordination from three different programs.
When the multi-process relationship is outside the console, things get messier still. The specific case that affected Yori users which I couldn't see how to handle is the Virtual Filesystem for Git agent, because launching a shell with a correct current directory does not mean the user can interact with the files there unless the agent is running. But the agent can be launched via any mechanism which may be completely unrelated to the console, so there's no knowledge indicating it must be restored. In the context of restoring a recently closed tab this may not be so problematic.
Obviously this is in addition to restoring state which depends on OS configuration which may not be present - having network shares, authentication, a particular IP address, a USB device attached - things that might change between attempting a save and a restore.
zadjii-msft commentedon May 24, 2019
Thanks Malcolm Smith (@malxau) for the great explanation. As we can see, restoring shell state is a neigh-impossible thing to do totally correct (and why I wanted this to have it's own thread separate from #766).
However buffer content is not impossible to restore. Lets make it opt-in, in addition to opting-in to general window state restore being tracked in #766.
malxau commentedon May 24, 2019
After sleeping on it, I started remembering even nastier cases about process relationships. Consider pipes: "type foo | more" means saving the state of the "type" command and the "more" command and somehow recreating the pipe. This looks like another cyclic dependency: pipes are normally created by the parent, which carefully hands one end to the child and closes it; but here we need some kind of resumable identifier that describes a pipe between two processes and can recreate that. The "type" command, in turn, needs to know where it was within its source stream to resume from; in this example with a source file that's at least possible.
When the source stream is dynamic, finding that point becomes somewhat meaningless. Suppose the command was "tasklist | more" - where should tasklist resume from? Its source stream has completely changed.
Agree with "neigh-impossible", and this feels like something where if we tried to solve it, it would end up being Windows-specific and a large part of the terminal effort is better interoperability with other platforms. It seems to me like if there was a push to solve this on other platforms we can contribute to the conversation, but going it alone doesn't seem like the right thing to do. Users would be left with an experience that only works for some programs, some of the time.
jamieghassibi commentedon Apr 4, 2020
Malcolm Smith (@malxau) While all the complications make saving state difficult, I don't feel simply saving the tabs, tab names, panes, and their respective directories should be relatively simple.
Having different session setups could also be possible as an argument to wt, for example I could type win+r
wt session footo open the foo session. Saving could be accomplished viawt session -s foo.Thinking about the above suggestion, it may be easier to add a section to the options JSON that let's users describe a session layout.
malxau commentedon Apr 4, 2020
Jamie Ghassibi (@jamieghassibi) How would the terminal obtain the directory that is active within the shell processes?
I can see how this would work if the session is defined in config, but to capture the current state into the config still sounds like it's depending on capturing state from the terminal and from all of the command line processes executing within it.
Chris-Dickerson commentedon May 7, 2020
I would like to see allowing a definition of tabs to be opened on startup (much like other Windows terminal applications).
As far as restoring state, I accept what happens in the terminal to be volatile. If I want the output, I capture it with the commands executed.
nmoinvaz commentedon May 21, 2020
It would be great if the Terminal could remember:
The actual contents of the buffer are not as important. When I restart my computer or accidentally close the Terminal app, I just want to get back to where I was as quickly as possible.
zadjii-msft commentedon May 22, 2020
Nathan Moin Vaziri (@nmoinvaz) So those two might be generically impossible for the Terminal to solve.
powershell/pwshandbashalready save the command history on exit.cmdis the one notorious exception, and it's not about to be updated to add that support, since that constantly burns us. See cmd: add environment variable to disable/enable 'Terminate batch job (Y/N)?' confirmation #217 (comment).50 remaining items
Implement buffer restore (#16598)
soroshsabz commentedon Mar 29, 2024
Mike Griese (@zadjii-msft) Did you know how to use this feature?
zadjii-msft commentedon Mar 29, 2024
This only just merged hours ago, so it's not available yet outside of just building the code from
maindirectly. Tonight's canary build should have this, though, our canary pipeline has been having some publishing issues this week.It should be enabled if you have
"firstWindowPreference": "persistedWindowLayout"enabled in your settings.ylluminate commentedon Jun 13, 2024
Is this supposed to be available in 1.20.11381.0? When I have the
"firstWindowPreference": "persistedWindowLayout"set, I still lose buffer / tab history upon restart, even though it does restart the sessions... My expectation from the parent request is that all of my history for various shells from PowerShell and cmd.exe to Ubuntu 24.04, etc. is all retained in perpetuity between Windows Terminal restarts...zadjii-msft commentedon Jun 13, 2024
Nope. This was added in 1.21.
mmseng commentedon Jun 13, 2024
I've been using it in the 1.21 Windows Terminal Preview. It does work as expected (for a certain definition of expected), however the vast majority of the times when I need it is when Windows updates reboot the machine, or when the machine otherwise reboots while Terminal is open, and from what I've seen I don't believe it's been working in these cases (I haven't been tracking it closely enough to make a more confident statement). As I recall, the failure due to Windows update reboots is an open issue.
edswangren commentedon Sep 10, 2024
this thread is so Windows. I don't mean to throw any shade at the devs and designers here, it's just that feeling of "@#(^#@^&" when my OS knocks me down with nagging and unwanted reboots only to hit me again by stealing more of my time, for years and years while my macs have never once hurt me this way. My mac picks me up when I'm down (<3 u my silver fox)
But seriously the comment above regarding that bastard known as perfection is 100% right. I mean, at least you can stop worrying about privacy, right? we've all used 11.
...well thanks for the hard work, that should serve as catharsis for now.
aschekatihin commentedon May 17, 2025
There should be ability to opt out of this behavior in settings. It is a bit distracting least to say.
mmseng commentedon May 17, 2025
You can:
However that also disables reopening your various tabs in the first place. It's not something that affects me personally, but I can definitely see why the buffer history preservation would be annoying, and why someone would still want to preserve their array of tabs between sessions without the buffer history.
I agree. Preserving tabs seems like a pre-requisite for preserving buffer history, but preserving buffer history shouldn't be required just to preserve tabs (after all that's how it worked before the introduction of buffer history). I'll also point out that the first posts in this issue discussed making the buffer restoration feature opt-in (or opt-out). But in the current state it is neither; it's just getting a free ride when you opt in to that existing "restore your tabs" setting.
I would probably recommend making a new issue for this, since this issue is closed.
aschekatihin commentedon May 23, 2025
Thank you Matt Seng (@mmseng) , you go everything perfectly right!
I guess I have to use this setting for now and lose ability to have custom terminals layout.
ylluminate commentedon May 23, 2025
Is someone going to open a new issue/ticket as per Matt Seng (@mmseng)'s suggestion? I was thinking about opening one, but I really stepped away from using Terminal in Windows quite a lot and I think it would be better that someone else who uses Windows more heavily vs macOS might want to give this important issues some love.
zadjii-msft commentedon May 23, 2025
Sounds like that request (be able to restore layout, but not buffer state) is tracked more-or-less in #18757