This one just simply didn't make the cut. Just sorting by □'s, this issue is below 12 other requests, 5 of which we're hoping to get done in 2.0. Right now, the best way of tracking that is through reactions on issues - not the best metric, no, but definitely something measurable. Users would be left with an experience that only works for some programs, some of the best way we have to prioritize features is based off of community feedback. 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. Suppose the command was "tasklist | more" - where should tasklist resume from? Its source stream has completely changed.Īgree 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. When the source stream is dynamic, finding that point becomes somewhat meaningless. 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. 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. Consider pipes: "type foo | more" means saving the state of the "type" command and the "more" command and somehow recreating the pipe. 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.Īfter sleeping on it, I started remembering even nastier cases about process relationships. In the context of restoring a recently closed tab this may not be so problematic. 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. 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. When the multi-process relationship is outside the console, things get messier still. Recovering things accurately would require coordination from three different programs. 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. 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.Ī clearer example of the same effect would be opening CMD and within that executing "vim foo". (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. Even if bothĬMD 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. One example was given previously: suppose the user launches a CMD window, and within that launches Powershell. Shell state includes things like current directory, environment, and in this case, aliases and command history.īut the real challenge is how to reason about multi-process relationships. Terminal state includes things like the size and position of the window, its contents, colors, and fonts. In that context, save/restore meant saving both terminal state as well as shell state. This was opt-in due to the security/privacy issue that mentioned, and is enabled with an environment variable. Firstly, welcome to github and the terminal project, adding to the record some of the information is referring to, I tried to implement save/restore of state as part of Yori, which is a CMD-like shell.
0 Comments
Leave a Reply. |