starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

megathread: Buffer exporting and logging #13295

New Issue
Open
opened 2026-01-31 03:39:05 +00:00 by claunia · 7 comments
claunia commented 2026-01-31 03:39:05 +00:00
Owner
Copy Link

Originally created by @zadjii-msft on GitHub (Apr 3, 2021).

[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

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 #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

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

SecureCRT logging settings

image

Originally created by @zadjii-msft on GitHub (Apr 3, 2021). ##### [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 * [ ] #11356: - From https://github.com/microsoft/terminal/pull/11062#discussion_r698586833: "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 #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.: ```json { "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 <details> <summary>PuTTY logging settings</summary> ![image](https://user-images.githubusercontent.com/18356694/131489911-736abf7c-9cf6-4528-b1a0-6b9991979b8a.png) See also: https://tartarus.org/~simon/putty-snapshots/htmldoc/Chapter4.html#config-logfilename </details> <details> <summary>SecureCRT logging settings</summary> ![image](https://user-images.githubusercontent.com/13182253/66295462-f5e10900-e91d-11e9-938c-7d8d8be51680.png) </details>
claunia commented 2026-01-31 03:39:06 +00:00
Author
Owner
Copy Link

@siliyuan6 commented on GitHub (Sep 27, 2023):

Can anyone teach me how to configure it? Why is the log file not automatically generated after I configured it? Are you modifying setting.json?Thank you all. My version is v1.17.11461.0

@siliyuan6 commented on GitHub (Sep 27, 2023): Can anyone teach me how to configure it? Why is the log file not automatically generated after I configured it? Are you modifying setting.json?Thank you all. My version is v1.17.11461.0
claunia commented 2026-01-31 03:39:06 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 28, 2023):

Why is the log file not automatically generated after I configured it?

Because this feature isn't actually implemented yet. What's in the OP was my spec-in-progress, which got turned into the draft spec over at #11090

@zadjii-msft commented on GitHub (Sep 28, 2023): > Why is the log file not automatically generated after I configured it? Because this feature isn't actually implemented yet. What's in the OP was my spec-in-progress, which got turned into the draft spec over at #11090
claunia commented 2026-01-31 03:39:06 +00:00
Author
Owner
Copy Link

@BlaskStone commented on GitHub (Nov 10, 2023):

will this feature be added next release version?

@BlaskStone commented on GitHub (Nov 10, 2023): will this feature be added next release version?
claunia commented 2026-01-31 03:39:06 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Nov 10, 2023):

@yuahualove Which feature? This megathread is tracking both exporting and auto-logging.

  • Buffer exporting has shipped since like, v1.12.
  • Auto-logging only ever had a rough spec draft, and hasn't been committed to any particular milestones.
@zadjii-msft commented on GitHub (Nov 10, 2023): @yuahualove Which feature? This megathread is tracking both exporting and auto-logging. * Buffer exporting has shipped since like, v1.12. * Auto-logging only ever had a rough spec draft, and hasn't been committed to any particular milestones.
claunia commented 2026-01-31 03:39:07 +00:00
Author
Owner
Copy Link

@mimmus commented on GitHub (Aug 20, 2024):

Buffer exporting is not enough because I have a login procedure going in error but not able to see all error messages because it cleare the terminal.
I need auto-logging.

@mimmus commented on GitHub (Aug 20, 2024): Buffer exporting is not enough because I have a login procedure going in error but not able to see all error messages because it cleare the terminal. I need auto-logging.
claunia commented 2026-01-31 03:39:07 +00:00
Author
Owner
Copy Link

@83nf15h commented on GitHub (Feb 28, 2025):

Any chance this come back to life in 2025? Would be great to have a save logs on exit option.

@83nf15h commented on GitHub (Feb 28, 2025): Any chance this come back to life in 2025? Would be great to have a save logs on exit option.
claunia commented 2026-01-31 03:39:07 +00:00
Author
Owner
Copy Link

@herrenP commented on GitHub (Jan 19, 2026):

Yes, autologging is needed. My computer may restart whenever IT feels like it.

It's a great app otherwise! 🙂

@herrenP commented on GitHub (Jan 19, 2026): Yes, autologging is needed. My computer may restart whenever IT feels like it. It's a great app otherwise! 🙂
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Settings Area-TerminalControl Area-UserInterface Issue-Scenario Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#13295
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?