Feature request: export console history as txt #912

@ChristophePichaud commented on GitHub (May 25, 2019):

Two options:

save the commands list
save the last command output

All with a right-click in a popup menu two items choice ?
I would be happy to implement that features.
I am looking at the source code to see where to impl it...

@ChristophePichaud commented on GitHub (May 25, 2019): Two options: - save the commands list - save the last command output All with a right-click in a popup menu two items choice ? I would be happy to implement that features. I am looking at the source code to see where to impl it...

claunia commented

@oising commented on GitHub (May 28, 2019):

@SjoerdNijboer @ChristophePichaud

The terminal can't distinguish between what a command is, nor what is strictly a result of its execution (its output.) All the terminal "sees" is the keys typed (raw input) and the screen buffer (raw output.) The decision as to what comprises a command can only be performed by the application handling it (cmd, bash, powershell etc.) So ultimately all the terminal can do is to save the output buffer for the current session (tab.)

@oising commented on GitHub (May 28, 2019): @SjoerdNijboer @ChristophePichaud The terminal can't distinguish between what a command is, nor what is strictly a result of its execution (its output.) All the terminal "sees" is the keys typed (raw input) and the screen buffer (raw output.) The decision as to what comprises a command can only be performed by the application handling it (cmd, bash, powershell etc.) So ultimately all the terminal can do is to save the output buffer for the current session (tab.)

claunia commented

@zadjii-msft commented on GitHub (Oct 3, 2019):

From @19317362 in #3044

I've tried WSL2 + docker + Windows Terminal. It's very good for developing.

It will be better if some features in SecureCRT & ConEmu can be introduced,

Save or redirect the output text in the terminal to some file with this feature
1. The format of the filename can be generated like yyyy-mm-dd_HH_MM_SS.log
   (like SecureCRT).
   This is very useful while using something like adb logcat etc.

2. Can change a new file while day changing.

3. File name has session name (just like SecureCRT & ConEmu

@zadjii-msft commented on GitHub (Oct 3, 2019): From @19317362 in #3044 > > # I've tried WSL2 + docker + Windows Terminal. It's very good for developing. > > It will be better if some features in SecureCRT & ConEmu can be introduced, > ## Save or redirect the output text in the terminal to some file with this feature > > 1. The format of the filename can be generated like yyyy-mm-dd_HH_MM_SS.log > (like SecureCRT). > This is very useful while using something like adb logcat etc. > > 2. Can change a new file while day changing. > > 3. File name has session name (just like SecureCRT & ConEmu

claunia commented

@19317362 commented on GitHub (Oct 7, 2019):

Perhaps this is a right click option within the console itself, or a setting to save and export on exit/closing tab.

But the option to save/export the console output and input into a txt file

This is a snap from SecueCRT. It's very useful for everything.

@19317362 commented on GitHub (Oct 7, 2019): > Perhaps this is a right click option within the console itself, or a setting to save and export on exit/closing tab. > > But the option to save/export the console output and input into a txt file This is a snap from SecueCRT. It's very useful for everything. ![CRT_20191007161704](https://user-images.githubusercontent.com/13182253/66295462-f5e10900-e91d-11e9-938c-7d8d8be51680.png)

claunia commented

@19317362 commented on GitHub (Oct 7, 2019):

Perhaps this is a right click option within the console itself, or a setting to save and export on exit/closing tab.

But the option to save/export the console output and input into a txt file

The menu item to Start/Stop logging in SecueCRT

@19317362 commented on GitHub (Oct 7, 2019): > Perhaps this is a right click option within the console itself, or a setting to save and export on exit/closing tab. > > But the option to save/export the console output and input into a txt file The menu item to Start/Stop logging in SecueCRT ![CRT_2](https://user-images.githubusercontent.com/13182253/66295815-bf57be00-e91e-11e9-85e2-acba7e58f053.png)

claunia commented

@19317362 commented on GitHub (Oct 7, 2019):

The similar feature of ConEmu.

@19317362 commented on GitHub (Oct 7, 2019): The similar feature of ConEmu. ![ConEmu](https://user-images.githubusercontent.com/13182253/66295997-2f664400-e91f-11e9-8b95-ce3094500247.png)

claunia commented

@yellow-starburst commented on GitHub (Jan 18, 2020):

Why has this not been pushed out yet as mentioned with conemu or cmder? Terminal would be great once this is fixed :)

@yellow-starburst commented on GitHub (Jan 18, 2020): Why has this not been pushed out yet as mentioned with conemu or cmder? Terminal would be great once this is fixed :)

claunia commented

@ChristophePichaud commented on GitHub (Jan 23, 2020):

I can handle it if you want.
Let me know if you are interested in.
Chris.

@ChristophePichaud commented on GitHub (Jan 23, 2020): I can handle it if you want. Let me know if you are interested in. Chris.

claunia commented

@zadjii-msft commented on GitHub (Jan 23, 2020):

@ChristophePichaud I think we'd love your contribution 😄

I think it'd be important to scope the work here, to try and get a handle on what could be accomplished in 1.0 vs 1.1+. IMO, just exporting the current buffer to a text file seems like something that could be accomplished in the 1.0 timeframe pretty reasonably, but more elaborate logging features like ComEmu might be harder to manage. Automatically logging the output to a file is what might require a more fully fledged spec. But I think it wouldn't be terribly hard to add a "Export to file" keybinding, or possibly even an action to the right click menu that's being added in #3789. That hardest part might be the file picker UI tbh 😝

If you really wanted to work on the more elaborate logging feature too, we'd certainly welcome that, but we'd probably want some sort of spec written up first 😉

As far as implementing the "export to file" action - I'd probably start by copying the Copy keybinding implementation - that's something similar that gets the text content from TermControl and attempts to handle it somehow in TerminalPage. I'd make the TermControl and Terminal figure out the string of text to report back as "the whole buffer", and then have TerminalPage figure out how to save that string of text. I'm happy to help with any questions you might have along the way

@zadjii-msft commented on GitHub (Jan 23, 2020): @ChristophePichaud I think we'd love your contribution 😄 I think it'd be important to scope the work here, to try and get a handle on what could be accomplished in 1.0 vs 1.1+. IMO, just exporting the current buffer to a text file seems like something that could be accomplished in the 1.0 timeframe pretty reasonably, but more elaborate logging features like ComEmu might be harder to manage. Automatically logging the output to a file is what might require a more fully fledged spec. But I think it wouldn't be terribly hard to add a "Export to file" keybinding, or possibly even an action to the right click menu that's being added in #3789. That hardest part might be the file picker UI tbh 😝 If you really wanted to work on the more elaborate logging feature too, we'd certainly welcome that, but we'd probably want some sort of [spec](https://github.com/microsoft/terminal/blob/master/doc/specs/spec-template.md) written up first 😉 As far as implementing the "export to file" action - I'd probably start by copying the Copy keybinding implementation - that's something similar that gets the text content from `TermControl` and attempts to handle it somehow in `TerminalPage`. I'd make the `TermControl` and `Terminal` figure out the string of text to report back as "the whole buffer", and then have `TerminalPage` figure out how to save that string of text. I'm happy to help with any questions you might have along the way

claunia commented

@ChristophePichaud commented on GitHub (Jan 27, 2020):

Windows Terminal - Save History Spec.docx
Here is a small spec (md file).

Solution Design

Using the Commands History vector, a combination of CTRL^S can open the common file dialog and save the history of commands in a text file.

It’s easy to do. Next, we could use a dialog to put the setting and the format of the logs.

But first, let’s save as raw text the various commands.

The problem of the setting UI is that it should be in XAML and I am not comfortable with that. But I can do the plumbing.

Let me know.

@ChristophePichaud commented on GitHub (Jan 27, 2020): [Windows Terminal - Save History Spec.docx](https://github.com/microsoft/terminal/files/4119159/Windows.Terminal.-.Save.History.Spec.docx) Here is a small spec (md file). ## Solution Design Using the Commands History vector, a combination of CTRL^S can open the common file dialog and save the history of commands in a text file. It’s easy to do. Next, we could use a dialog to put the setting and the format of the logs. But first, let’s save as raw text the various commands. The problem of the setting UI is that it should be in XAML and I am not comfortable with that. But I can do the plumbing. Let me know.

claunia commented

@ChristophePichaud commented on GitHub (Jan 28, 2020):

It could be something like this:
InteractivityWin32 - WindowsIO.cpp

    if (VirtualKeyCode == VK_F10 &&
        bKeyDown &&
        inputKeyInfo.HasNoModifiers() &&
        ShouldTakeOverKeyboardShortcuts())
    {
        auto& cookedReadData = ServiceLocator::LocateGlobals().getConsoleInformation().CookedReadData();
        auto history = cookedReadData.History();
        size_t commandCount = history->GetNumberOfCommands();
        std::wstring all_command;
        for (SHORT i = 0; i < commandCount; ++i)
        {
            std::wstring_view str = history->GetNth(i);
            all_command += str;
            all_command += std::wstring(L"\r\n");
        }
        ::MessageBox(NULL, all_command.c_str(), NULL, MB_OK);
        // replace MsgBox by file i/o writefile and hop its done with the date_time.log
        // then later, provide an UI for cutsom stuff logging format
        return;
    }

@ChristophePichaud commented on GitHub (Jan 28, 2020): It could be something like this: InteractivityWin32 - WindowsIO.cpp if (VirtualKeyCode == VK_F10 && bKeyDown && inputKeyInfo.HasNoModifiers() && ShouldTakeOverKeyboardShortcuts()) { auto& cookedReadData = ServiceLocator::LocateGlobals().getConsoleInformation().CookedReadData(); auto history = cookedReadData.History(); size_t commandCount = history->GetNumberOfCommands(); std::wstring all_command; for (SHORT i = 0; i < commandCount; ++i) { std::wstring_view str = history->GetNth(i); all_command += str; all_command += std::wstring(L"\r\n"); } ::MessageBox(NULL, all_command.c_str(), NULL, MB_OK); // replace MsgBox by file i/o writefile and hop its done with the date_time.log // then later, provide an UI for cutsom stuff logging format return; }

claunia commented

2026-01-30 22:09:59 +00:00

@ChristophePichaud commented on GitHub (Jan 28, 2020):

There is also another solution... Log every time we have a new command:
host - readDataCooked.cpp line 1000 in _handlePostCharInputLoop()

    if (FoundCR)
    {
        if (_commandHistory)
        {
            // add to command line recall list if we have a history list.
            CONSOLE_INFORMATION& gci = ServiceLocator::LocateGlobals().getConsoleInformation();
            LOG_IF_FAILED(_commandHistory->Add({ _backupLimit, StringLength / sizeof(wchar_t) },
                                               WI_IsFlagSet(gci.Flags, CONSOLE_HISTORY_NODUP)));

            // It's dirty but it works
            wchar_t tempPath[MAX_PATH];
            DWORD dwPath = MAX_PATH;
            ::GetTempPath(dwPath, tempPath);

            std::wstring wpath = tempPath + std::wstring(L"WindowsTerminal.log");

            std::wstring_view buffer(_backupLimit, StringLength / sizeof(wchar_t));
            std::wofstream ofs(wpath, std::ios_base::app);
            ofs << buffer << std::endl;
            ofs.close();
        }

        // check for alias
        ProcessAliases(LineCount);
    }

@ChristophePichaud commented on GitHub (Jan 28, 2020): There is also another solution... Log every time we have a new command: host - readDataCooked.cpp line 1000 in _handlePostCharInputLoop() if (FoundCR) { if (_commandHistory) { // add to command line recall list if we have a history list. CONSOLE_INFORMATION& gci = ServiceLocator::LocateGlobals().getConsoleInformation(); LOG_IF_FAILED(_commandHistory->Add({ _backupLimit, StringLength / sizeof(wchar_t) }, WI_IsFlagSet(gci.Flags, CONSOLE_HISTORY_NODUP))); // It's dirty but it works wchar_t tempPath[MAX_PATH]; DWORD dwPath = MAX_PATH; ::GetTempPath(dwPath, tempPath); std::wstring wpath = tempPath + std::wstring(L"WindowsTerminal.log"); std::wstring_view buffer(_backupLimit, StringLength / sizeof(wchar_t)); std::wofstream ofs(wpath, std::ios_base::app); ofs << buffer << std::endl; ofs.close(); } // check for alias ProcessAliases(LineCount); }

claunia commented

@zadjii-msft commented on GitHub (Jan 28, 2020):

Ah so there might be a bit of a miscommunication here - I think we're each thinking of a different thing as the "console history".

I'm thinking of the entirety of the output that's been emitted to the console. So for a console that looks like:

I'm thinking of the entire text:

Microsoft Windows [Version 10.0.19552.1001]
(c) 2020 Microsoft Corporation. All rights reserved.

[ 7:48:55.94]>C:\Users\migrie>
migrie@MIGRIE-SLAPTOP>echo "Foo"
"Foo"

[ 7:49:01.24]>C:\Users\migrie>
migrie@MIGRIE-SLAPTOP>dir | $ grep foo
01/27/2020  02:32 PM                 8 #foo#
09/03/2019  09:52 AM                 8 foo
11/14/2019  11:59 AM                12 foo.txt

[ 7:49:12.43]>C:\Users\migrie>
migrie@MIGRIE-SLAPTOP>

It sounds to me like you want just the command history. So in the above case, it would be just the following:

echo "Foo"
dir | $ grep foo

I think there might be some challenges in saving just the second one. Windows Terminal is fundamentally just a terminal emulator, it doesn't really know what's going on behind the scenes with whatever client application (cmd, powershell, bash, vim) that is connected to it. WT doesn't know when the user is typing in commands to the shell, or if the user is just typing in text in emacs or something. There's no way for the terminal to know that. It's typically the client application's responsibility to save it's own command history. bash and powershell bot do a pretty good job of saving this to another file to restore across sessions, while cmd.exe doesn't.

Of course, Windows is a messy world and this model gets a little tricky here. cmd.exe isn't actually managing it's own command history at all - as you've noticed, conhost is doing that work on behalf of the client applications. Some long time ago someone thought it would be a good idea to have the readline functionality baked directly into the console host. Whether that was a good idea or not remains to be seen - it's certainly made things like python.exe's REPL easier to implement, since they don't need to maintain their own history buffer, but it makes it hard to de-tangle behavior like this from the console itself.

I'm not sure how it would be possible to add a keybinding to the Windows Terminal that would be able to save the console's command history. Especially considering the Terminal might not be connected to a console host session at all. If the Windows Terminal were directly running a wsl instance (something that's not possible today, but something we've considered adding in the future), then there wouldn't be a conhost in the process tree at all, and now requesting the command history from the console wouldn't work mysteriously.

I still think that writing the entire buffer history to a file is something that's very possible, since that's something that's entirely known by the Terminal.

@zadjii-msft commented on GitHub (Jan 28, 2020): Ah so there might be a bit of a miscommunication here - I think we're each thinking of a different thing as the "console history". I'm thinking of the entirety of the output that's been emitted to the console. So for a console that looks like: ![image](https://user-images.githubusercontent.com/18356694/73269590-baa36800-41a2-11ea-9191-baadbf966b71.png) I'm thinking of the entire text: ``` Microsoft Windows [Version 10.0.19552.1001] (c) 2020 Microsoft Corporation. All rights reserved. [ 7:48:55.94]>C:\Users\migrie> migrie@MIGRIE-SLAPTOP>echo "Foo" "Foo" [ 7:49:01.24]>C:\Users\migrie> migrie@MIGRIE-SLAPTOP>dir | $ grep foo 01/27/2020 02:32 PM 8 #foo# 09/03/2019 09:52 AM 8 foo 11/14/2019 11:59 AM 12 foo.txt [ 7:49:12.43]>C:\Users\migrie> migrie@MIGRIE-SLAPTOP> ``` It sounds to me like you want _just the command history_. So in the above case, it would be just the following: ``` echo "Foo" dir | $ grep foo ``` I think there might be some challenges in saving just the second one. Windows Terminal is fundamentally just a _terminal emulator_, it doesn't really know what's going on behind the scenes with whatever client application (`cmd`, `powershell`, `bash`, `vim`) that is connected to it. WT doesn't know when the user is typing in commands to the shell, or if the user is just typing in text in `emacs` or something. There's no way for the terminal to know that. It's _typically_ the client application's responsibility to save it's own command history. `bash` and `powershell` bot do a pretty good job of saving this to another file to restore across sessions, while `cmd.exe` doesn't. Of course, Windows is a messy world and this model gets a little tricky here. `cmd.exe` isn't actually managing it's own command history _at all_ - as you've noticed, `conhost` is doing that work on behalf of the client applications. Some long time ago someone thought it would be a good idea to have the `readline` functionality baked directly into the console host. Whether that was a good idea or not remains to be seen - it's certainly made things like `python.exe`'s REPL easier to implement, since they don't need to maintain their own history buffer, but it makes it hard to de-tangle behavior like this from the console itself. I'm not sure how it would be possible to add a keybinding to the Windows Terminal that would be able to save the console's _command_ history. Especially considering the Terminal might _not_ be connected to a console host session at all. If the Windows Terminal were directly running a `wsl` instance (something that's not possible today, but something we've considered adding in the future), then there wouldn't be a `conhost` in the process tree at all, and now requesting the command history from the console wouldn't work _mysteriously_. I still think that writing the _entire buffer history_ to a file is something that's _very_ possible, since that's something that's entirely known by the Terminal.

claunia commented

2026-01-30 22:09:59 +00:00

@eryksun commented on GitHub (Jan 31, 2020):

it's certainly made things like python.exe's REPL easier to implement, since they don't need to maintain their own history buffer, but it makes it hard to de-tangle behavior like this from the console itself.

It's easy, but it makes the Windows implementation of Python the odd man out. Without support for Python's readline extension module, it can't use the REPL's ".python_history" file. There's a third-party pyreadline package, but it's poorly maintained and based on a ctypes FFI wrapper for the console API.

For saving just the input command history (as opposed to the entire session history of the terminal), it's better to use a Readline library that supports the Windows console. In that regard what I'd really want is for Microsoft to provide a C API for Readline support in console applications. It could support Windows, Emacs, and Vi modies, like PSReadLine in PowerShell.

Barring rewriting a console app to support readline (a la PowerShell), the console API could at least provide a more complete and documented implementation of its command history. It could document the functions for reading and clearing the session command history (i.e. GetConsoleCommandHistoryLengthW, GetConsoleCommandHistoryW, and ExpungeConsoleCommandHistoryW), which doskey.exe has used for almost 30 years. Plus extend the API with the ability to overwrite the command history -- e.g. SetConsoleCommandHistoryW(lpCommands, dwLength, lpExename).

@eryksun commented on GitHub (Jan 31, 2020): > it's certainly made things like `python.exe`'s REPL easier to implement, since they don't need to maintain their own history buffer, but it makes it hard to de-tangle behavior like this from the console itself. It's easy, but it makes the Windows implementation of Python the odd man out. Without support for Python's readline extension module, it can't use the REPL's ".python_history" file. There's a third-party pyreadline package, but it's poorly maintained and based on a ctypes FFI wrapper for the console API. For saving just the input command history (as opposed to the entire session history of the terminal), it's better to use a Readline library that supports the Windows console. In that regard what I'd really want is for Microsoft to provide a C API for Readline support in console applications. It could support Windows, Emacs, and Vi modies, like PSReadLine in PowerShell. Barring rewriting a console app to support readline (a la PowerShell), the console API could at least provide a more complete and documented implementation of its command history. It could document the functions for reading and clearing the session command history (i.e. `GetConsoleCommandHistoryLengthW`, `GetConsoleCommandHistoryW`, and `ExpungeConsoleCommandHistoryW`), which doskey.exe has used for almost 30 years. Plus extend the API with the ability to overwrite the command history -- e.g. `SetConsoleCommandHistoryW(lpCommands, dwLength, lpExename)`.

claunia commented

2026-01-30 22:09:59 +00:00

@jamesbtate commented on GitHub (Jun 9, 2020):

Has anyone taken on this feature request? Is there anything someone new to the project with no C++ experience can do to help it along?

My use case is mainly system administration with the ability to look back at commands and output from hours/days/weeks ago.

@jamesbtate commented on GitHub (Jun 9, 2020): Has anyone taken on this feature request? Is there anything someone new to the project with no C++ experience can do to help it along? My use case is mainly system administration with the ability to look back at commands and output from hours/days/weeks ago.

claunia commented

2026-01-30 22:10:00 +00:00

@buscseik commented on GitHub (Jul 4, 2020):

Also, time stamping each logged line in log file would be a very usueful option

@buscseik commented on GitHub (Jul 4, 2020): Also, time stamping each logged line in log file would be a very usueful option

claunia commented

2026-01-30 22:10:00 +00:00

@brettus78 commented on GitHub (Jul 8, 2020):

Would be very useful to have sessions always and continuously log - with options for different files per session or per profile list item with the custom options of append, overwrite, new file (with some options for formatting with date/time/profile list item name, etc.), and an ability to not log certain sessions - so per profile list item would swell. Maybe option to start a new file each time the sesssion opens
Something like PuTTY/MobaXTerm/TeraTerm.

{
    "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}",
    "hidden": false,
    "name": "Azure Cloud Shell",
    "source": "Windows.Terminal.Azure",
    "logfile_location":"C:\\Users\\myuser\\logs\\",
    "logfile_format":"%name%_%date%_%time%.log",
    "logfile_type":"new_file"/"append_existing"/"etc.",
}

@brettus78 commented on GitHub (Jul 8, 2020): Would be very useful to have sessions always and continuously log - with options for different files per session or per profile list item with the custom options of append, overwrite, new file (with some options for formatting with date/time/profile list item name, etc.), and an ability to not log certain sessions - so per profile list item would swell. Maybe option to start a new file each time the sesssion opens Something like PuTTY/MobaXTerm/TeraTerm. ``` { "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}", "hidden": false, "name": "Azure Cloud Shell", "source": "Windows.Terminal.Azure", "logfile_location":"C:\\Users\\myuser\\logs\\", "logfile_format":"%name%_%date%_%time%.log", "logfile_type":"new_file"/"append_existing"/"etc.", } ```

claunia commented

2026-01-30 22:10:01 +00:00

@Mayhem93 commented on GitHub (Sep 16, 2020):

I think what most people want is to save the whole console's buffer into a file, I've came across this issue while googling if such a thing is possible (because I had a ton of logs, and scrolling was cumbersome and wanted to open in vscode for processing).

So here's my 👍 for this feature. Instead of having right-click do the paste action we could have a context menu where this paste action and "save terminal output" options would be available (not to mention, the menu can be expanded easily). Other option is to have this request feature as an option in the context menu of the tab (when right-clicking)

@Mayhem93 commented on GitHub (Sep 16, 2020): I think what most people want is to save the whole console's buffer into a file, I've came across this issue while googling if such a thing is possible (because I had a ton of logs, and scrolling was cumbersome and wanted to open in vscode for processing). So here's my 👍 for this feature. Instead of having right-click do the paste action we could have a context menu where this paste action and "save terminal output" options would be available (not to mention, the menu can be expanded easily). Other option is to have this request feature as an option in the context menu of the tab (when right-clicking)

claunia commented

2026-01-30 22:10:01 +00:00

@rmutchler commented on GitHub (Oct 2, 2020):

Leaving my vote on here for this feature too. I use this with PuTTY and MobaXterm to automatically log every session to a new file. It is useful when I configure a SAN or switch. I can save the files if there is a dispute on the work performed or go back and review if there is an issue during a session.

@rmutchler commented on GitHub (Oct 2, 2020): Leaving my vote on here for this feature too. I use this with PuTTY and MobaXterm to automatically log every session to a new file. It is useful when I configure a SAN or switch. I can save the files if there is a dispute on the work performed or go back and review if there is an issue during a session.

claunia commented

2026-01-30 22:10:02 +00:00

@chadministratorwastaken commented on GitHub (Dec 17, 2020):

This is the only feature keeping me from switching to WT. Literally the only one.
Just sayin'
It's the only one.
Just. one.

@chadministratorwastaken commented on GitHub (Dec 17, 2020): This is the only feature keeping me from switching to WT. Literally the only one. Just sayin' It's the only one. Just. one.

claunia commented

2026-01-30 22:10:02 +00:00

@ChristophePichaud commented on GitHub (Dec 17, 2020):

It is decided, I run into the study to implement a decent contrition for implementing thios feature.
@miniksa @zadjii-msft Do you agree to give me green light ?
I can do it in less than 1 month or 6 weeks maximum. I have already studied and prototyped it before....
Regards, Christophe | www.windowscpp.com

@ChristophePichaud commented on GitHub (Dec 17, 2020): It is decided, I run into the study to implement a decent contrition for implementing thios feature. @miniksa @zadjii-msft Do you agree to give me green light ? I can do it in less than 1 month or 6 weeks maximum. I have already studied and prototyped it before.... Regards, Christophe | www.windowscpp.com

claunia commented

2026-01-30 22:10:02 +00:00

@zadjii-msft commented on GitHub (Dec 17, 2020):

Sure, go right ahead. I think starting with just an action to export the current buffer contents to a file would be a good enough place to start. We can work on building things like auto-logging to a file, or hooking that action up to the tab context menu, etc. after that.

Also as a heads up, it is about to be the holidays here, so we might not be super responsive until the new year, but I'll try answering any questions you might have. Looking forward to the PR!

@zadjii-msft commented on GitHub (Dec 17, 2020): Sure, go right ahead. I think starting with just an action to export the current buffer contents to a file would be a good enough place to start. We can work on building things like auto-logging to a file, or hooking that action up to the tab context menu, etc. after that. Also as a heads up, it is about to be the holidays here, so we might not be super responsive until the new year, but I'll try answering any questions you might have. Looking forward to the PR!

claunia commented

2026-01-30 22:10:03 +00:00

@alainza commented on GitHub (Dec 18, 2020):

Right click inside the console window might be assigned to "Paste" like in cmd's window: why not add the "Save" command to the popup menu on the tab header ?

@alainza commented on GitHub (Dec 18, 2020): Right click inside the console window might be assigned to "Paste" like in cmd's window: why not add the "Save" command to the popup menu on the tab header ?

claunia commented

2026-01-30 22:10:03 +00:00

@ChristophePichaud commented on GitHub (Dec 19, 2020):

I tell you all that this feature will be done by me and my young Infeeny Expert Kevin ANSARD, a student working with me. See our blog at blog.infeeny.com... Consulting Services. .NET and Azure... Microsoft ecosystem of Partners. See www.Infeeny.com.
We are in Paris, France.

@ChristophePichaud commented on GitHub (Dec 19, 2020): I tell you all that this feature will be done by me and my young Infeeny Expert Kevin ANSARD, a student working with me. See our blog at blog.infeeny.com... Consulting Services. .NET and Azure... Microsoft ecosystem of Partners. See www.Infeeny.com. We are in Paris, France.

claunia commented

2026-01-30 22:10:03 +00:00

@chadministratorwastaken commented on GitHub (Jan 7, 2021):

@ChristophePichaud @zadjii-msft I would be very happy to test this new feature when it is available. Thank you very much for working on it!

@chadministratorwastaken commented on GitHub (Jan 7, 2021): @ChristophePichaud @zadjii-msft I would be very happy to test this new feature when it is available. Thank you very much for working on it!

claunia commented

2026-01-30 22:10:04 +00:00

@fischerdouglas commented on GitHub (Jan 22, 2021):

This is a Mus-Have!
For those who work with IT support, this is a powerful shield against unfair complaints of errors on the operations of systems.

And what is needed is the FULL TEXT of the session, in live mode... Including backspaces and retyping.

And is needed ALSO for the remote sessions like remote Powershell, or remote ssh/telnet.

@fischerdouglas commented on GitHub (Jan 22, 2021): This is a Mus-Have! For those who work with IT support, this is a powerful shield against unfair complaints of errors on the operations of systems. And what is needed is the FULL TEXT of the session, in live mode... Including backspaces and retyping. And is needed ALSO for the remote sessions like remote Powershell, or remote ssh/telnet.

claunia commented

2026-01-30 22:10:04 +00:00

@ChristophePichaud commented on GitHub (Jan 22, 2021):

Hello Douglas,

Keep calm 😳😎, I implement it on cmd, then we discuss and then, we do a UI for settings and next, last but not last, we do it also for PowerShell and bash....
Every command prompt has a low level filter and a common one for all.
It's not so easy it is supposed to be.
I release on next Friday, the 29 January for testing.

Chris

Get Outlook for Androidhttps://aka.ms/ghei36

@ChristophePichaud commented on GitHub (Jan 22, 2021): Hello Douglas, Keep calm 😳😎, I implement it on cmd, then we discuss and then, we do a UI for settings and next, last but not last, we do it also for PowerShell and bash.... Every command prompt has a low level filter and a common one for all. It's not so easy it is supposed to be. I release on next Friday, the 29 January for testing. Chris Get Outlook for Android<https://aka.ms/ghei36> Get Outlook for Android<https://aka.ms/ghei36>

claunia commented

@zadjii-msft commented on GitHub (Jan 22, 2021):

Hey I just wanted to make sure there wasn't a miscommunication here - how exactly are you going about doing this?

IMO, there's probably 4 steps to this PR:

Create a new Action that can be bound by the user in TerminalApp/Terminal.Settings.Model, that will call some function in TermControl. #8522 is a good example of a PR that wires up all the things you'd need for the action, and calls down to the active control. The Copy action might be another good example, since that gets some text from the control, and returns it up to the app layer.
In the function added to TermControl query the buffer for all the lines of text. I believe TextBuffer exposes a way to get all the text from a row - should just be a matter of iterating over the entire contents of the buffer.
Return those buffer contents up to the TerminalApp layer.
In TerminalApp, open up a file picker dialog to chose a file to write those contents to.

At that point, the user should be able to execute the "exportHistory" action (either with a keybinding or the command palette), and be prompted with a file picker, which should let them write the buffer contents to a file. We can work on other settings like auto logging, or logging keystrokes, etc. in the future, but this should be good enough for the 90% use case for now.

I don't think this needs to do anything different depending on which shell the user's interacting with, so that gives me pause...

@zadjii-msft commented on GitHub (Jan 22, 2021): Hey I just wanted to make sure there wasn't a miscommunication here - how exactly are you going about doing this? IMO, there's probably 4 steps to this PR: 1. Create a new Action that can be bound by the user in `TerminalApp`/`Terminal.Settings.Model`, that will call some function in `TermControl`. #8522 is a good example of a PR that wires up all the things you'd need for the action, and calls down to the active control. The `Copy` action might be another good example, since that gets some text from the control, and returns it up to the app layer. 2. In the function added to `TermControl` query the buffer for all the lines of text. I believe `TextBuffer` exposes a way to get all the text from a row - should just be a matter of iterating over the entire contents of the buffer. 3. Return those buffer contents up to the `TerminalApp` layer. 4. In `TerminalApp`, open up a file picker dialog to chose a file to write those contents to. At that point, the user should be able to execute the "exportHistory" action (either with a keybinding or the command palette), and be prompted with a file picker, which should let them write the buffer contents to a file. We can work on other settings like auto logging, or logging keystrokes, etc. in the future, but this should be good enough for the 90% use case for now. I don't _think_ this needs to do anything different depending on which shell the user's interacting with, so that gives me pause...

claunia commented

@ChristophePichaud commented on GitHub (Jan 22, 2021):

Ok I understand. No problem about the issue.

Chris.

Get Outlook for Androidhttps://aka.ms/ghei36

@ChristophePichaud commented on GitHub (Jan 22, 2021): Ok I understand. No problem about the issue. Chris. Get Outlook for Android<https://aka.ms/ghei36>

claunia commented

@chadministratorwastaken commented on GitHub (Jan 22, 2021):

@zadjii-msft @ChristophePichaud The way I read the request was that automatic logging was a key part of this feature. Manually exporting the history via the command palette is no more easier than manually copying and pasting the text myself. Automatic logging is critical to my use case since I know it captures everything, even if I forget to export, and is not affected by any limitations of printed history.

If a comparison is helpful, I currently use the logging feature in PuTTY, which is the functionality I hope to see in wt.

@chadministratorwastaken commented on GitHub (Jan 22, 2021): @zadjii-msft @ChristophePichaud The way I read the request was that automatic logging was a key part of this feature. Manually exporting the history via the command palette is no more easier than manually copying and pasting the text myself. Automatic logging is critical to my use case since I know it captures everything, even if I forget to export, and is not affected by any limitations of printed history. If a comparison is helpful, I currently use the logging feature in PuTTY, which is the functionality I hope to see in wt.

claunia commented

@zadjii-msft commented on GitHub (Jan 25, 2021):

See, I'm very much a "steady, small incremental improvement" kinda person. I'd much rather work on what I've laid out first, then do keystrokes too, then add auto-logging, rather than try to accomplish all three at once and have it land sometime on the other side of never. Doing this first little bit will make the other parts easier in the future.

One step at a time 😄

@zadjii-msft commented on GitHub (Jan 25, 2021): See, I'm very much a "steady, small incremental improvement" kinda person. I'd much rather work on what I've laid out first, then do keystrokes too, then add auto-logging, rather than try to accomplish all three at once and have it land sometime on the other side of _never_. Doing this first little bit will make the other parts easier in the future. One step at a time 😄

claunia commented

2026-01-30 22:10:06 +00:00

@chadministratorwastaken commented on GitHub (Jan 25, 2021):

Fair enough. I'm just glad there's movement! Thanks again for your attention to this :)

@chadministratorwastaken commented on GitHub (Jan 25, 2021): Fair enough. I'm just glad there's movement! Thanks again for your attention to this :)

claunia commented

@fischerdouglas commented on GitHub (Jan 25, 2021):

I didn't understand the complexity behind the scenes...
But I'm not a developer, so I even try to do it(srsrs).

But to be clear, I don't believe that any type of treatment should be done to the text.
Nothing like splitting what is a command and what is an output of the commando...

Simple real-time piping of all the characters presented on the screen > $LogFile

And when I say Real-time, I do not care about being pretty on the output file...

For example, if you look to and output a file of a session where the "htop" was used, it will be craziness... With characters been rewritten every second...
No issues with that! That's exactly what I need.
Including writing and backspacing characters...

Exactly as it happens on iTerm2 or even on SecureCRT as mentioned by our colleague earlier.

Perhaps this is a right click option within the console itself, or a setting to save and export on exit/closing tab.
But the option to save/export the console output and input into a txt file

This is a snap from SecueCRT. It's very useful for everything.

@fischerdouglas commented on GitHub (Jan 25, 2021): I didn't understand the complexity behind the scenes... But I'm not a developer, so I even try to do it(srsrs). But to be clear, I don't believe that any type of treatment should be done to the text. Nothing like splitting what is a command and what is an output of the commando... Simple real-time piping of all the characters presented on the screen > $LogFile And when I say Real-time, I do not care about being pretty on the output file... For example, if you look to and output a file of a session where the "htop" was used, it will be craziness... With characters been rewritten every second... No issues with that! That's exactly what I need. Including writing and backspacing characters... Exactly as it happens on iTerm2 or even on SecureCRT as mentioned by our colleague earlier. > > Perhaps this is a right click option within the console itself, or a setting to save and export on exit/closing tab. > > But the option to save/export the console output and input into a txt file > > This is a snap from SecueCRT. It's very useful for everything. > > ![CRT_20191007161704](https://user-images.githubusercontent.com/13182253/66295462-f5e10900-e91d-11e9-938c-7d8d8be51680.png)

claunia commented

2026-01-30 22:10:06 +00:00

@ChristophePichaud commented on GitHub (Feb 3, 2021):

OK, it seems pretty cool locally OK.
I have worked disconnected since 3 weeks and I have most of the feature that seemz working.
I write "mosté and "seems" because it's not so easy it's look from the outside of the c++ code...
I need to do some additionnal quality and checks before releasing the code online in the PR and doing the code review step check.
Let me some hours/few days before completing the job.
I go online and I ask you for review but I think it's good.

Christophe

@ChristophePichaud commented on GitHub (Feb 3, 2021): OK, it seems pretty cool locally OK. I have worked disconnected since 3 weeks and I have most of the feature that seemz working. I write "mosté and "seems" because it's not so easy it's look from the outside of the c++ code... I need to do some additionnal quality and checks before releasing the code online in the PR and doing the code review step check. Let me some hours/few days before completing the job. I go online and I ask you for review but I think it's good. Christophe

claunia commented

2026-01-30 22:10:06 +00:00

@WSLUser commented on GitHub (Feb 8, 2021):

So I should mention that the built-in Hyperterminal from XP had this feature. See this old article from Cisco on how it worked: https://www.cisco.com/c/en/us/support/docs/routers/2500-series-routers/17521-capture-text-hyperterminal.html. When I was still administering network devices, this was such a useful tool. I'm sure the source code still exists somewhere in the Windows repository and could be ported/refactored/modernized to work in conhost and/or Windows Terminal at least.

@WSLUser commented on GitHub (Feb 8, 2021): So I should mention that the built-in Hyperterminal from XP had this feature. See this old article from Cisco on how it worked: https://www.cisco.com/c/en/us/support/docs/routers/2500-series-routers/17521-capture-text-hyperterminal.html. When I was still administering network devices, this was such a useful tool. I'm sure the source code still exists somewhere in the Windows repository and could be ported/refactored/modernized to work in conhost and/or Windows Terminal at least.

claunia commented

@miniksa commented on GitHub (Feb 8, 2021):

So I should mention that the built-in Hyperterminal from XP had this feature. See this old article from Cisco on how it worked: cisco.com/c/en/us/support/docs/routers/2500-series-routers/17521-capture-text-hyperterminal.html. When I was still administering network devices, this was such a useful tool. I'm sure the source code still exists somewhere in the Windows repository and could be ported/refactored/modernized to work in conhost and/or Windows Terminal at least.

I'm 95% sure that HyperTerminal was a product that Microsoft licensed to include in previous editions of Windows, not something that is built out of the Windows repository with source code. Kinda like the 3D Pinball thing.

Having a source code example isn't really what's stopping us from getting this done anyway. It's just time, priority, and resources. (And pandemic fatigue.)

@miniksa commented on GitHub (Feb 8, 2021): > So I should mention that the built-in Hyperterminal from XP had this feature. See this old article from Cisco on how it worked: [cisco.com/c/en/us/support/docs/routers/2500-series-routers/17521-capture-text-hyperterminal.html](https://www.cisco.com/c/en/us/support/docs/routers/2500-series-routers/17521-capture-text-hyperterminal.html). When I was still administering network devices, this was such a useful tool. I'm sure the source code still exists somewhere in the Windows repository and could be ported/refactored/modernized to work in conhost and/or Windows Terminal at least. I'm 95% sure that HyperTerminal was a product that Microsoft licensed to include in previous editions of Windows, not something that is built out of the Windows repository with source code. Kinda like the 3D Pinball thing. Having a source code example isn't really what's stopping us from getting this done anyway. It's just time, priority, and resources. (And pandemic fatigue.)

claunia commented

@WSLUser commented on GitHub (Feb 8, 2021):

I did see something that made me wonder if that was the case. Still, by now that license should of expired. I haven't seen it used outside of older Windows so it ought to be able to be acquired by Microsoft and/or OSSed. I just would love to see this feature pop up even on conhost appearing similar to how it does in HyperTerminal (because nolstagia and it's conhost). I of course would expect something more prettified for Windows Terminal due to a different UI framework being used.

@WSLUser commented on GitHub (Feb 8, 2021): I did see something that made me wonder if that was the case. Still, by now that license should of expired. I haven't seen it used outside of older Windows so it ought to be able to be acquired by Microsoft and/or OSSed. I just would love to see this feature pop up even on conhost appearing similar to how it does in HyperTerminal (because nolstagia and it's conhost). I of course would expect something more prettified for Windows Terminal due to a different UI framework being used.

claunia commented

@ChristophePichaud commented on GitHub (Feb 12, 2021):

I have a question for you @zadjii-msft ... I was releasing my code from offline to connected GitHub and I realized that when I was reading one of your last comment that I made it the wrong way.
Let me explain:

I was dealiong with the CMD command prompt and I was handling string buffer from InteractivityWin32 - WindowsIO.cpp and host - readDataCooked.cpp line 1000 in _handlePostCharInputLoop...
=> THE Problem is that is only handling CMD.
Your last coments told me to handle the string buffer from the XAML Main Window, correct ?
handling events from XAML Foundation Windows stuff ? Correct ???
Christophe

<<
ChristophePichaud commented on Jan 28, 2020
It could be something like this:
InteractivityWin32 - WindowsIO.cpp

if (VirtualKeyCode == VK_F10 &&
    bKeyDown &&
    inputKeyInfo.HasNoModifiers() &&
    ShouldTakeOverKeyboardShortcuts())
{
    auto& cookedReadData = ServiceLocator::LocateGlobals().getConsoleInformation().CookedReadData();
    auto history = cookedReadData.History();
    size_t commandCount = history->GetNumberOfCommands();
    std::wstring all_command;
    for (SHORT i = 0; i < commandCount; ++i)
    {
        std::wstring_view str = history->GetNth(i);
        all_command += str;
        all_command += std::wstring(L"\r\n");
    }
    ::MessageBox(NULL, all_command.c_str(), NULL, MB_OK);
    // replace MsgBox by file i/o writefile and hop its done with the date_time.log
    // then later, provide an UI for cutsom stuff logging format
    return;
}

AND

ChristophePichaud commented on Jan 28, 2020 •
There is also another solution... Log every time we have a new command:
host - readDataCooked.cpp line 1000 in _handlePostCharInputLoop()

if (FoundCR)
{
    if (_commandHistory)
    {
        // add to command line recall list if we have a history list.
        CONSOLE_INFORMATION& gci = ServiceLocator::LocateGlobals().getConsoleInformation();
        LOG_IF_FAILED(_commandHistory->Add({ _backupLimit, StringLength / sizeof(wchar_t) },
                                           WI_IsFlagSet(gci.Flags, CONSOLE_HISTORY_NODUP)));

        // It's dirty but it works
        wchar_t tempPath[MAX_PATH];
        DWORD dwPath = MAX_PATH;
        ::GetTempPath(dwPath, tempPath);

        std::wstring wpath = tempPath + std::wstring(L"WindowsTerminal.log");

        std::wstring_view buffer(_backupLimit, StringLength / sizeof(wchar_t));
        std::wofstream ofs(wpath, std::ios_base::app);
        ofs << buffer << std::endl;
        ofs.close();
    }

    // check for alias
    ProcessAliases(LineCount);
}

@ChristophePichaud commented on GitHub (Feb 12, 2021): I have a question for you @zadjii-msft ... I was releasing my code from offline to connected GitHub and I realized that when I was reading one of your last comment that I made it the wrong way. Let me explain: - I was dealiong with the CMD command prompt and I was handling string buffer from InteractivityWin32 - WindowsIO.cpp and host - readDataCooked.cpp line 1000 in _handlePostCharInputLoop... => THE Problem is that is only handling CMD. Your last coments told me to handle the string buffer from the XAML Main Window, correct ? handling events from XAML Foundation Windows stuff ? Correct ??? Christophe - - << ChristophePichaud commented on Jan 28, 2020 It could be something like this: InteractivityWin32 - WindowsIO.cpp if (VirtualKeyCode == VK_F10 && bKeyDown && inputKeyInfo.HasNoModifiers() && ShouldTakeOverKeyboardShortcuts()) { auto& cookedReadData = ServiceLocator::LocateGlobals().getConsoleInformation().CookedReadData(); auto history = cookedReadData.History(); size_t commandCount = history->GetNumberOfCommands(); std::wstring all_command; for (SHORT i = 0; i < commandCount; ++i) { std::wstring_view str = history->GetNth(i); all_command += str; all_command += std::wstring(L"\r\n"); } ::MessageBox(NULL, all_command.c_str(), NULL, MB_OK); // replace MsgBox by file i/o writefile and hop its done with the date_time.log // then later, provide an UI for cutsom stuff logging format return; } AND ChristophePichaud commented on Jan 28, 2020 • There is also another solution... Log every time we have a new command: host - readDataCooked.cpp line 1000 in _handlePostCharInputLoop() if (FoundCR) { if (_commandHistory) { // add to command line recall list if we have a history list. CONSOLE_INFORMATION& gci = ServiceLocator::LocateGlobals().getConsoleInformation(); LOG_IF_FAILED(_commandHistory->Add({ _backupLimit, StringLength / sizeof(wchar_t) }, WI_IsFlagSet(gci.Flags, CONSOLE_HISTORY_NODUP))); // It's dirty but it works wchar_t tempPath[MAX_PATH]; DWORD dwPath = MAX_PATH; ::GetTempPath(dwPath, tempPath); std::wstring wpath = tempPath + std::wstring(L"WindowsTerminal.log"); std::wstring_view buffer(_backupLimit, StringLength / sizeof(wchar_t)); std::wofstream ofs(wpath, std::ios_base::app); ofs << buffer << std::endl; ofs.close(); } // check for alias ProcessAliases(LineCount); } >>

claunia commented

@zadjii-msft commented on GitHub (Feb 12, 2021):

@ChristophePichaud Yea, don't mess with any of that. readData, interactivity, WindowsIO - all that's conhost-specific code. We don't care about adding this to conhost right now (and that's certainly much harder). We're not trying to log each individual command as they come in, because that's not as useful, and doesn't work for powershell, bash, etc.

It's more useful, and easier to start with, just writing the entire buffer contents to a file. I think this can be done in just the Terminal, in TerminalControl, TerminalApp and TerminalSettingsModel. That's where we're generally adding new UX features.

@zadjii-msft commented on GitHub (Feb 12, 2021): @ChristophePichaud Yea, don't mess with _any_ of that. `readData`, interactivity, `WindowsIO` - all that's conhost-specific code. We don't care about adding this to conhost right now (and that's certainly much harder). We're not trying to log each individual _command_ as they come in, because that's not as useful, and doesn't work for powershell, bash, etc. It's more useful, and easier to start with, just writing the _entire_ buffer contents to a file. I think this can be done in just the Terminal, in TerminalControl, TerminalApp and TerminalSettingsModel. That's where we're generally adding new UX features.

claunia commented

@ChristophePichaud commented on GitHub (Feb 12, 2021):

Yes, thanks for you support.
I have deep dived in TermApp and TermControl 7 days ago and I saw the IDL and winrt/cpp generated code stuff in CPP files.
I looked at some Winrt samples to catch the "Copy" Command. I can't see the light. Can't realize how to declare this kind of Foundation events methods IDL winrt stuff in the code.
I have the code sniper for getting the buffer.
I have got the code for appending the buffer into the rolling daily log file using log4cpp...
But the XAML UI handling with Foundation hurt me.

I search but would be really appreciated to see where to declare the WinUI plumbing to handle this mouse handlers...

@Alain Zanchettamailto:alainza@hotmail.com, you can give me an advice ???

Regards to all..
Chris

Get Outlook for Androidhttps://aka.ms/ghei36

@ChristophePichaud commented on GitHub (Feb 12, 2021): Yes, thanks for you support. I have deep dived in TermApp and TermControl 7 days ago and I saw the IDL and winrt/cpp generated code stuff in CPP files. I looked at some Winrt samples to catch the "Copy" Command. I can't see the light. Can't realize how to declare this kind of Foundation events methods IDL winrt stuff in the code. I have the code sniper for getting the buffer. I have got the code for appending the buffer into the rolling daily log file using log4cpp... But the XAML UI handling with Foundation hurt me. I search but would be really appreciated to see where to declare the WinUI plumbing to handle this mouse handlers... @Alain Zanchetta<mailto:alainza@hotmail.com>, you can give me an advice ??? Regards to all.. Chris Get Outlook for Android<https://aka.ms/ghei36>

claunia commented

@zadjii-msft commented on GitHub (Feb 12, 2021):

@ChristophePichaud Try taking a look at #8917. That's a PR that has a good example of plumbing an action from TerminalApp down into the TermControl.

@zadjii-msft commented on GitHub (Feb 12, 2021): @ChristophePichaud Try taking a look at #8917. That's a PR that has a good example of plumbing an action from TerminalApp down into the TermControl.

claunia commented

@alainza commented on GitHub (Feb 12, 2021):

@ChristophePichaud You don't need to change idl.

Just register your code in void TerminalTab::_CreateContextMenu() in https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/TerminalTab.cpp

i.e. right click in the body of the tab is already used for "paste" => don't mess up with this
right click on a tab header is where you already have a menu and adding "save tab content as text" would make sense.
This is done in void TerminalTab::_CreateContextMenu()

@alainza commented on GitHub (Feb 12, 2021): @ChristophePichaud You don't need to change idl. Just register your code in `void TerminalTab::_CreateContextMenu() `in https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/TerminalTab.cpp i.e. right click in the body of the tab is already used for "paste" => don't mess up with this right click on a tab header is where you already have a menu and adding "save tab content as text" would make sense. This is done in `void TerminalTab::_CreateContextMenu()`

claunia commented

@ChristophePichaud commented on GitHub (Feb 12, 2021):

Thank Alain. I try this asap.
Damn XAML Foundation stuff.....
I hope God bless Frogs. 😳😘😎
Chris, from Paris, France.

Get Outlook for Androidhttps://aka.ms/ghei36

@ChristophePichaud commented on GitHub (Feb 12, 2021): Thank Alain. I try this asap. Damn XAML Foundation stuff..... I hope God bless Frogs. 😳😘😎 Chris, from Paris, France. Get Outlook for Android<https://aka.ms/ghei36>

claunia commented

@ChristophePichaud commented on GitHub (Feb 12, 2021):

Thanks Mike.
I will go into this.
I can do it.

Get Outlook for Androidhttps://aka.ms/ghei36

@ChristophePichaud commented on GitHub (Feb 12, 2021): Thanks Mike. I will go into this. I can do it. Get Outlook for Android<https://aka.ms/ghei36>

claunia commented

@chadministratorwastaken commented on GitHub (Mar 17, 2021):

Are there any updates on this? Is there anything I can do to assist?

@chadministratorwastaken commented on GitHub (Mar 17, 2021): Are there any updates on this? Is there anything I can do to assist?

claunia commented

@ChristophePichaud commented on GitHub (Mar 17, 2021):

Hello,

I am busy on track.
It was hard to find the plumbing _CreateCOntext from my friend Alain Zanchetta.
It’s still under development on local branch.
I may be still be busy this coming days few hours but I’am near the end.
The XAML was a problem for me.
Do you want to fix a final deadline to be on track ?

Christophe

De : chadministratorwastaken @.>
Envoyé : Wednesday, March 17, 2021 2:15 PM
À : microsoft/terminal @.>
Cc : Christophe Pichaud @.>; Mention @.>
Objet : Re: [microsoft/terminal] Feature request: export console history as txt (#642)

Are there any updates on this? Is there anything I can do to assist?

@ChristophePichaud commented on GitHub (Mar 17, 2021): Hello, I am busy on track. It was hard to find the plumbing _CreateCOntext from my friend Alain Zanchetta. It’s still under development on local branch. I may be still be busy this coming days few hours but I’am near the end. The XAML was a problem for me. Do you want to fix a final deadline to be on track ? Christophe De : chadministratorwastaken ***@***.***> Envoyé : Wednesday, March 17, 2021 2:15 PM À : microsoft/terminal ***@***.***> Cc : Christophe Pichaud ***@***.***>; Mention ***@***.***> Objet : Re: [microsoft/terminal] Feature request: export console history as txt (#642) Are there any updates on this? Is there anything I can do to assist?

claunia commented

@zadjii-msft commented on GitHub (May 19, 2021):

Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button?

That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️

@zadjii-msft commented on GitHub (May 19, 2021): Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button? ![image](https://user-images.githubusercontent.com/18356694/91237459-5cbb0c80-e700-11ea-9347-b9b1ec2813b1.png) That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️

claunia commented

@kczx3 commented on GitHub (May 24, 2021):

This would be very useful as I work in some apps that produce a lot of output and I can't always direct it to a file on the remote server to then grab via SCP. So being able to start terminal output logging, run a command, and then view that output locally is immensely helpful (and quicker).

@kczx3 commented on GitHub (May 24, 2021): This would be very useful as I work in some apps that produce a lot of output and I can't always direct it to a file on the remote server to then grab via SCP. So being able to start terminal output logging, run a command, and then view that output locally is immensely helpful (and quicker).

claunia commented

@zadjii-msft commented on GitHub (Jun 10, 2021):

@konarx If you'd like to "+1" this feature, the best way to do that is by hitting the 👍 button on this issue

That way, you avoid unnecessarily pinging everyone following this thread. Thanks!

@zadjii-msft commented on GitHub (Jun 10, 2021): @konarx If you'd like to "+1" this feature, the best way to do that is by hitting the 👍 button on this issue ![image](https://user-images.githubusercontent.com/18356694/96140789-ef3c8880-0ec5-11eb-82e0-30ce4977b9a7.png) That way, you avoid unnecessarily pinging everyone following this thread. Thanks!

claunia commented

@chadministratorwastaken commented on GitHub (Jul 19, 2021):

Has this request been reduced in priority? It's been four months since we've heard from the last person to agree to take it on.

@chadministratorwastaken commented on GitHub (Jul 19, 2021): Has this request been reduced in priority? It's been four months since we've heard from the last person to agree to take it on.

claunia commented

@zadjii-msft commented on GitHub (Jul 19, 2021):

FWIW @ChristophePichaud is an external contributor - it's entirely reasonable that life happened and they never got around to finishing this.

@zadjii-msft commented on GitHub (Jul 19, 2021): FWIW @ChristophePichaud is an external contributor - it's entirely reasonable that _life happened_ and they never got around to finishing this.

claunia commented

@Don-Vito commented on GitHub (Aug 26, 2021):

@zadjii-msft - WDYT?

@Don-Vito commented on GitHub (Aug 26, 2021): ![ExportPane](https://user-images.githubusercontent.com/4639110/131033955-e3dace15-dd93-4e14-865e-79ade5ab7364.gif) @zadjii-msft - WDYT?

claunia commented

@alainza commented on GitHub (Aug 26, 2021):

Seems cool to me ! When do we get this :) ?

@alainza commented on GitHub (Aug 26, 2021): Seems cool to me ! When do we get this :) ?

claunia commented

@zadjii-msft commented on GitHub (Aug 26, 2021):

What do I think? I think

ship it

@zadjii-msft commented on GitHub (Aug 26, 2021): What do I think? I think ![image](https://user-images.githubusercontent.com/18356694/131038075-557a2477-8d24-42cb-b7c5-d1d7595b7877.png) # ship it

claunia commented

@kczx3 commented on GitHub (Aug 27, 2021):

How does that work with scrollable regions? (I think that’s the proper terminology)

@kczx3 commented on GitHub (Aug 27, 2021): How does that work with scrollable regions? (I think that’s the proper terminology)

claunia commented

@DHowett commented on GitHub (Aug 27, 2021):

How does that work with scrollable regions? (I think that’s the proper terminology)

Terrible secret... Terminal itself doesn't know about the scrolling regions. There's an issue tracking that; right now they work because there's a console in the background doing all the translation.

@DHowett commented on GitHub (Aug 27, 2021): > How does that work with scrollable regions? (I think that’s the proper terminology) Terrible secret... Terminal itself doesn't know about the scrolling regions. There's an issue tracking that; right now they work because there's a console in the background doing all the translation.

claunia commented

@buscseik commented on GitHub (Aug 27, 2021):

I would like to convince people in this thread, exporting is not the same as logging.

With logging you can introduce new additional options like:

timestamping terminal output.
Automatically started logging when new terminal is opened.
File naming convention.

With the export feature:
What happen if scroll back buffer is full?
For example, what will happen if I would like to set up a logging for an entry week, and 10 lines of output is captured every second. whit this "export" solution I will have to check over and over again and save manually the output, and after find the duplicated lines manually, and join the logs manually.

What will happen, if the terminal, or the laptop crash before I can export the log?

@buscseik commented on GitHub (Aug 27, 2021): I would like to convince people in this thread, exporting is not the same as logging. With logging you can introduce new additional options like: - timestamping terminal output. - Automatically started logging when new terminal is opened. - File naming convention. With the export feature: What happen if scroll back buffer is full? For example, what will happen if I would like to set up a logging for an entry week, and 10 lines of output is captured every second. whit this "export" solution I will have to check over and over again and save manually the output, and after find the duplicated lines manually, and join the logs manually. What will happen, if the terminal, or the laptop crash before I can export the log?

claunia commented

@buscseik commented on GitHub (Aug 27, 2021):

Just a small workaround.

You can create a script which will start logging automatically when you open a new terminal window.
Just type $Profile and hit enter to find the profile script which will started automatically when you open a new terminal window.
If the listed script file does not exists, just create it.
Add following content to the file and save it:

$timestamp= get-date -U "%Y%m%d-%H%M%S"
$Folder = "d:\pslogs\"
Start-Transcript $Folder$timestamp.txt
# delete older than 30 days logs
Get-ChildItem $Folder | where LastWriteTime -lt $(Get-Date).AddDays(-30) | del -Force

Make sure the D:\pslogs\ folder is created before you start to use it.

@buscseik commented on GitHub (Aug 27, 2021): Just a small workaround. You can create a script which will start logging automatically when you open a new terminal window. Just type $Profile and hit enter to find the profile script which will started automatically when you open a new terminal window. If the listed script file does not exists, just create it. Add following content to the file and save it: $timestamp= get-date -U "%Y%m%d-%H%M%S" $Folder = "d:\pslogs\" Start-Transcript $Folder$timestamp.txt # delete older than 30 days logs Get-ChildItem $Folder | where LastWriteTime -lt $(Get-Date).AddDays(-30) | del -Force Make sure the D:\pslogs\ folder is created before you start to use it.

claunia commented

@Don-Vito commented on GitHub (Aug 27, 2021):

I would like to convince people in this thread, exporting is not the same as logging.

With logging you can introduce new additional options like:

timestamping terminal output.

Automatically started logging when new terminal is opened.

File naming convention.

With the export feature:
What happen if scroll back buffer is full?
For example, what will happen if I would like to set up a logging for an entry week, and 10 lines of output is captured every second. whit this "export" solution I will have to check over and over again and save manually the output, and after find the duplicated lines manually, and join the logs manually.

What will happen, if the terminal, or the laptop crash before I can export the log?

I absolutely agree that we need to add the logging as well. I started with a pull for export as it is a "low hanging fruit" that will hopefully be useful for some (it helps me personally 👼)

I will try to look at logging later on. Everyone else is encouraged as well 😊

@Don-Vito commented on GitHub (Aug 27, 2021): > I would like to convince people in this thread, exporting is not the same as logging. > > With logging you can introduce new additional options like: > - timestamping terminal output. > - Automatically started logging when new terminal is opened. > - File naming convention. > > With the export feature: > What happen if scroll back buffer is full? > For example, what will happen if I would like to set up a logging for an entry week, and 10 lines of output is captured every second. whit this "export" solution I will have to check over and over again and save manually the output, and after find the duplicated lines manually, and join the logs manually. > > What will happen, if the terminal, or the laptop crash before I can export the log? I absolutely agree that we need to add the logging as well. I started with a pull for export as it is a "low hanging fruit" that will hopefully be useful for some (it helps me personally :angel:) I will try to look at logging later on. Everyone else is encouraged as well :blush:

claunia commented

@fischerdouglas commented on GitHub (Sep 1, 2021):

First-> I need to say that I'm pretty happy seem some movements ( #11090 ) to solve this demand...

And I Agree with @Don-Vito and @buscseik when they say that "exporting is not the same as logging".
But I also need to reinforce that both are needed...

Just to exemplify, in some tools(like iTerm2) real time logging means that if you type "wrod" and press backspace 3 times end write "ord", is exactly those 10 chars that will be at the log.
And on export you will see only "word"...

This may sound silly, but just with that level of logging will be possible to have registered "CTRL+C" or "CTRL+A" sent to remote terminals...

Another side effect of logging (this one is annoying) is when you access CLI apps that draw on screen and refresh every second. Most apps done with ncurses on linux do that... Examples of what I'm saying are "top" "sngrep" on linux, or the old "edit" from msdos.
When you see that on the log file, it looks a mess... But is an acceptable downside of being safe and having the logs of what you did on some one else server or equipment.

@fischerdouglas commented on GitHub (Sep 1, 2021): First-> I need to say that I'm pretty happy seem some movements ( #11090 ) to solve this demand... And I Agree with @Don-Vito and @buscseik when they say that "exporting is not the same as logging". But I also need to reinforce that both are needed... Just to exemplify, in some tools(like iTerm2) real time logging means that if you type "wrod" and press backspace 3 times end write "ord", is exactly those 10 chars that will be at the log. And on export you will see only "word"... This may sound silly, but just with that level of logging will be possible to have registered "CTRL+C" or "CTRL+A" sent to remote terminals... Another side effect of logging (this one is annoying) is when you access CLI apps that draw on screen and refresh every second. Most apps done with ncurses on linux do that... Examples of what I'm saying are "top" "sngrep" on linux, or the old "edit" from msdos. When you see that on the log file, it looks a mess... But is an acceptable downside of being safe and having the logs of what you did on some one else server or equipment.

claunia commented

@zadjii-msft commented on GitHub (Sep 1, 2021):

Just to be clear - no one thinks that exporting and logging are the same thing. This is just a nice stepping stone towards full logging. I encourage anyone with thoughts on the matter to go check out #11090.

@zadjii-msft commented on GitHub (Sep 1, 2021): Just to be clear - no one thinks that exporting and logging are the same thing. This is just a nice stepping stone towards full logging. I encourage anyone with thoughts on the matter to go check out #11090.

claunia commented

@oising commented on GitHub (Sep 1, 2021):

Blergh... this is gonna be fun. Personally I believe that exporting is fine, but logging responsibility belongs to the shell, not the terminal. Do I really want to know if someone typo'd 67 times before successfully executing sudo rm -Rf / ? Maybe if I was Sherlock Holmes and wanted hints about the perpetrator... ;)

And as far as logging goes, powershell is wayyyy ahead of the curve with respect to that: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows?view=powershell-7.1

@oising commented on GitHub (Sep 1, 2021): Blergh... this is gonna be fun. Personally I believe that exporting is fine, but logging responsibility belongs to the shell, not the terminal. Do I really want to know if someone typo'd 67 times before successfully executing `sudo rm -Rf /` ? Maybe if I was Sherlock Holmes and wanted hints about the perpetrator... ;) And as far as logging goes, powershell is wayyyy ahead of the curve with respect to that: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows?view=powershell-7.1

claunia commented

@RokeJulianLockhart commented on GitHub (Sep 6, 2021):

This has been a feature of http://github.com/kde/konsole since many years before now, and is equally important as it is basic, so this should be added soon.

@RokeJulianLockhart commented on GitHub (Sep 6, 2021): This has been a feature of http://github.com/kde/konsole since many years before now, and is equally important as it is basic, so this should be added soon.

claunia commented

@zadjii-msft commented on GitHub (Sep 6, 2021):

so this should be added soon.

Well great news, #11062 was just merged last week!

@zadjii-msft commented on GitHub (Sep 6, 2021): > so this should be added soon. Well great news, #11062 was just merged last week!

claunia commented

@RokeJulianLockhart commented on GitHub (Sep 7, 2021):

http://github.com/microsoft/terminal/issues/642#issuecomment-913865402

Thus, this issue probably should be closed.

@RokeJulianLockhart commented on GitHub (Sep 7, 2021): > http://github.com/microsoft/terminal/issues/642#issuecomment-913865402 Thus, [this issue](http://github.com/microsoft/terminal/issues/642) probably should be closed.

claunia commented