WinBox (4.1) remembers and restores open windows after reconnects, except for Terminal contents. The Terminal windows re-open, but they're set back to empty history and a fresh command prompt.
Feature request: Have WinBox remember Terminal contents: after reconnect, re-display the window history, and restore the command prompt to /wherever/it/was.
This would be particularly useful if running /log/print [follow] or /tool/sniffer/packet print [follow] commands while testing things that can cause reconnections.
Think that it would need to much effort to store these contents per router session + per terminal window opened as one could close Winbox with many terminals active.
The Windows CMD.EXE (in Windows 11 modern times, the Windows Terminal app) can remember thousands of lines, per window/CMD tab, for however many windows/tabs; My typical client computer has tens of gigabytes of RAM, and terabytes of storage; It could be an opt-in in case people have very limited client systems, but I can't see how resource contraints could justify not implementing the feature.
And, given frequent disconnects/reconnects in typical management/ debugging scenarios, which cause the loss of this information, it would be very useful to have.
First, your correct it does not "background terminal on disconnect". The logic like deliberate that winbox-disconnect == terminal-disconnection. While you could argue this should be an option, and this be possible... as a default, it be very bad as most folks do expect terminals (and their CPU/etc) usage goes aways with the winbox window. And like "hardest" of your multi-pronged complaints... since the issue of how to handle "orphaned" ones in non-trivial / complex UX (e.g. when you do NOT re-connect, what happens?).
But you're wrong about "history". Both Ctrl+R and should work the same after a reconnection. Older terminal windows in winbox, do not...but this largely follow UNIX conventions
And you're right again that winbox does not remember the path /"directory" of the terminal when it restores window after reconnect. Perhaps this be useful in some cases. But the recent command history is global, so even if window was in a same path after re-connection... you'd have the problem that there is only one history, so whether that was more/less helpful be random, and be be confusing to most that assume a new window starts at the root.
Apologies. Indeed, I do NOT mean "history" as in command recall.
I mean "the contents of the window, the output of past commands".
(Though, I do still want each Terminal to remember its local path, and return to that, along with re-displaying/ still displaying the recent commands' outputs).
Regarding orphaned sessions, the Winbox could discard things "older than" (configurable). [As I recall, this was a setting on UNIX ages ago, when reconnetable ttys became a thing; reconnectable .. but not forever). The feature that I'm asking for is "Don't lose the recent output in each open Winbox's open Terminal window" where "recent" is "Whatever I'm configuring/ debugging at the moment", which (though configurable) usually wouldn't be more than a few hours/days. That's well within reasonable resource requirements for most client systems running Winbox.
You suggest that "most folks expect terminals (and CPU) usage to go away with the Winbox window". If I killed Winbox I'd expect stuff to go away. This is about the network connection between a still-running Winbox and a MikroTik router going away (and, before "too long" - hours, days - coming back/ being re-connected by the user). So, with network-disconnecting-between-Winbox-and-MikroTik, I would not expect Winbox resources to be released.
Each feature request should stand, or fall, on its own merits.
About the feature I am requesting: What do YOU do, when you want to e.g. /tool/sniffer/packet print follow, or /log/print follow, while either doing things that will cause temporary disconnections, or on a not-entirely-reliable connection to the router?
Of course, you could syslog to a remote database, or packet capture to a remote analyzer .. but that requires setting up extra infrastructure, and probably not all things that the administrator would want to watch in a terminal window have easy log-to-remote options.
@optio re: "screen" for ROS Terminal .. yes, except that screen would run on the router, and because the routers are not often very powerful, and have better things to do with their time, and the "to what disconnected pty should THIS Winbox's THIS Terminal window reconnect" problem would be complex, really, no, it's not "screen". It's just having Winbox Terminal remember what it last showed.
If you go in such direction IMO better to be screen like feature with configurable buffer size to avoid RAM consumption and possibility to list, attach to/detach from and terminate sessions, but I doubt it will be implemented. Send feature request to support and see what will answer.
It could save the buffer to the session file (if there is still one), and restore the buffer with a terminated command. That only use PC-based storage. So you'd at least not lose the "output-to-date" if winbox disconnects and windows are being restored. Now this still may not be possible since the "sessions" can apply to multiple hosts, so perhaps ONLY if profile <own> would this even be possible.
It's the "runs in background" if disconnected part that I do not support. Even if I "liked it", I don't think it is practical: both from a UX and technical POVs. e.g. winbox connection is what own the terminal: so no winbox, no terminal... & also given how winbox seemingly works, see Open-Source Python Reimplementation of WinBox Terminal Access)
When the disconnection happens and the WinBox connection is severed, I expect and want the terminal sessions inside it to close, with all sub-processes (commands) that they spawn. The routers have limited CPU and memory resources. I don't want those processes that monitor and parse stuffs to continue and stay in the background.
What I could find interesting: see the output of the interrupted terminal session when reconnecting Winbox session. A feature I do not want, the reason for my downvote: resume magically the command where it was interrupted.
@libove
You could make use of a little of the tens of gigabytes of RAM and terabytes of storage you have, and schedule on your windows PC an automatic screen capture every - say - 5 seconds to be started every time you start winbox.
Than you could OCR each screenshot and store the data in a SQL database for easy retrieval.
I think we should separate out the restoring running commands after disconnect (most against this idea, including the "safe mode" problem)... from the more modest: Terminal windows should remember the buffer text with the output of PAST commands restored to the window after re-connection but running command gets killed. For example, sleep/hibernate often do save terminal window buffers, but sometimes the running command may be terminated (depends on OS/type-of-sleep).
well, at that point you'd be better off using SSH... or figuring out how to avoid winbox disconnecting in the first place. Generally a disconnect happens when some config broke something ... not a sniffer/touch/other-long-running-monitor-command.
should work the same after a reconnection. Older terminal windows in winbox, do not...but this largely follow UNIX conventions
