megathread: Buffer exporting and logging

[zadjii-msft]

[Original thread: #642] [Spec: #11090 {in progress}] [#11062]

This thread is being used to track all the component work for buffer logging and exporting.

2.0 Bugs

• [1.12] Exporting text fails when running elevated (presumably we can't open the file picker elevated) #11356:
  • From Allow exporting terminal buffer into file via tab context menu #11062 (comment): "It is pickers, of all sorts, through the W.S API that is broken, not any specific individual use. We may try/catch this one, but... the best we can do is simply not pop up a dialog when Admin."

Buffer exporting

This is the easier work to do. #11062 already wires up the TerminalApp to retrieve the buffer contents from the TermControl, so writing them at request is easy.

• I think the path should just be a single setting, a file path, rather than two settings, directory and filename. When we have formatted paths, then that's both settings in one line.

• Add an exportBuffer() action that opens the file picker
• Add a string path parameter to exportBuffer() that allows the user to press a key and immediately export the buffer to a whole path
  • default to "", which indicates "open the file picker"
• add a boolean append (default to false) parameter to exportBuffer. When true, export to the file given by appending, not overwriting the file
• Enable string formatting in the path parameter.
  • What format do we want? yyyy-mm-dd? %Y-%m-%D? &Y-&m-&D? {year}-{month}-{day}?
  • What are all the variables we want?
    • Year, month, day, hour, minute - those are easy
    • WT_SESSION, for a uuid for eash session maybe?
    • Profile name perhaps? Commandline?
• more...

Automatic logging

This is harder. We don't want the TermControl telling the TerminalApp layer about every piece of output logged. That would be insane, especially in the post-#5000 world where that's a cross-process hop. Instead, we'll want the ControlCore/ControlInteractivity to do logging themselves. I suppose that this should have been tracked in #3044 separately from #642, but here we are.

• toggleLogging() Action for start/stop logging, with path, append properties (like exportBuffer())
  • ToggleLoggingArgs contains a single member LoggingSettings, which contains path and append properties. This will make sense below.
• add LoggingSettings property for "log all output" (default would just be "log printable output")
• add LoggingSettings property for "log input" (Though, we'd probably want to log it as normal VT encoded, not as win32-input encoded)
• Per-profile setting for "auto logging", which would log by default when the profile is opened Terminal Output Logging Functionality #14018
  • So we want to have a profile have both "logging settings" and a "log automatically" property? So "start logging" on a profile that has logging settings, but doesn't log automatically would just use the profile's settings? e.g.:

{
  "actions": [
    { "command": "toggleLogging" }
  ],
  "profiles": [
    {
      "name": "foo",
      "logging": { "path": "c:\foo.txt", "append": true },
      "automaticallyLog": false
    }
  ]
}

• LoggingSettings property for "New file every day", which only works when the {day} is in the path string. When auto-logging with this setting, opens a new file at midnight and starts writing that one.
• LoggingSettings property for "Flush log frequently", defaults to true(?). This causes us to flush all output to the file, instead of just... on close? on newline? It's unclear exactly when PuTTY flushes with this off. Need more coffee.

Initially I thought it might be nice to have LoggingSettings be the same for exportBuffer() and profile.logging. But newFileEveryDay and flushFrequently don't make sense for exportBuffer(). Though I guess they do make sense for toggleLogging()

Reference

PuTTY logging settings

See also: https://tartarus.org/~simon/putty-snapshots/htmldoc/Chapter4.html#config-logfilename

SecureCRT logging settings