Disparity between PSReadLine + *-History commands creates confusion

[Jaykul]

Given that the decision has been made to require and integrate an external module PSReadLine for command handling, it's confusing ( PowerShell/PowerShell#5711 #1074 ) and redundant to have two copies of the history, and the commands which modify history should be made to (optionally?) modify both.

Right now, the PowerShell History is numbered, and supports re-invoking via Invoke-History (or r) and also via tab-completion like #1{Tab}, but PSReadLine owns the hotkeys and search!

The PSReadLine history is persistent, but only the PowerShell History has commands to import/export/clear it -- which allow one to modify what's stored in the history in the case one accidentally types something one doesn't want logged.

Obviously there's a substantial difference between them, architecturally -- since PSReadLine's history only contains the actual command-lines, but the actual history retrieved by Get-History includes the status, as well as the start and end time...

However, this dichotomy, combined with the use of bash-similar aliases (history and r etc) and hotkeys which sometimes return different (or no) results is confusing and should be resolved -- ideally, by having the history commands work on (or appear to work on) the same (size) persistent history buffer as PSReadLine.

[lzybkr]

This is essentially a duplicate of #120 - which I'll point out has been open for more than 3 years and there is essentially no discussion, so maybe it's not a big problem.

[Jaykul]

There have been at least two other bugs filed here about parts of that.
I wouldn't call four bugs "essentially no discussion" 😕

[essentialexch]

I've said in other places (and will repeat here) that I don't think PSReadLine should be included by default in PS 6.0.

Don't get me wrong, I love PSReadLine. But the inconsistencies DO confuse admin-scripters (and they have no idea where to get their issues heard and they blame it, reasonably enough, on buggy Microsoft code) and PSReadLine just increases the size of the PS 6.x distribution for all platforms, even though PSReadLine will never be used on most computers.

[rkeithhill]

If you don't include PSReadLine by default on Linux and macOS, you might as well pack it up and go home. Without PSRL, PowerShell line editing is too far behind Bash for folks to take PowerShell seriously - on those platforms.

You can add Remove-Module PSReadLine to your profile to remove it - if that's what you'd prefer - even on PS Core.

[essentialexch]

Or the few -- perhaps 1% or less -- of computers that need an interactive editing experience can install the module - even on PS Core. You are suggesting that the burden -- the FAR LARGER BURDEN -- of removing the install be placed on most of those computers that don't need it. At best, that's silly.

Still not relevant to the core issue (see what I did there?) here -- that PSReadLine doesn't properly integrate with *-History. Which it should.

[rkeithhill]

Well then for the "99%" of the time that PS Core is not interactively used, how is PSRL any sort of problem? Especially considering that PSReadLine doesn't get imported in non-interactive cases (see PowerShell/PowerShell#5087):

14:3ms> pwsh -command "& {gmo}"

ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Manifest   3.1.0.0    Microsoft.PowerShell.Utility        {Add-Member, Add-Type, Clear-Variable, Compare-Object...}

[essentialexch]

As I wrote a couple of comments above: "Don't get me wrong, I love PSReadLine. But the inconsistencies DO confuse admin-scripters (and they have no idea where to get their issues heard and they blame it, reasonably enough, on buggy Microsoft code) and PSReadLine just increases the size of the PS 6.x distribution for all platforms, even though PSReadLine will never be used on most computers."

I don't know about the 99% number I used, but I am certain that in the Azure environments I build, interactive PowerShell never touches those computers. That's all done on a DevOps computer. In the goal to make server containers and nano server "as small as possible" PSRL surely has impact, especially when multipled by thousands of operating system environments where it is never used.

[rkeithhill]

PSReadLine just increases the size of the PS 6.x distribution for all platforms

But by only 0.44%. The PSRL module is 550KB (200KB is for docs that could be removed) out of 125MB for a 64-bit PS Core 6.0.0 install on Windows 10.

Admittedly those sizes are taken from my Windows 10 dev machine. I haven't looked at a container image for PS Core to see if they've done any work to strip it down.

FWIW a good number of bugs will be fixed by the 2.0.0 release of PSRL. Hopefully that will calm folks down some. :-)

[Jaykul]

For the record (here in the future): July ended with 3.97M startups of PowerShell Core 6. 82% of them on Linux. I think we can end the debate about whether it's needed: clearly the vast majority of people using PS6 are on Linux and therefore need a ReadLine module.

[essentialexch]

No.

[msftrncs]

Just noting, the two histories are drastically different. (while they look so similar)

PSReadLine's history is for persistent memory of the commands that have been entered, regardless of whether they were executed. (although that is all optional)

PowerShell's own history is for a single session's interactive commands that have been executed. (don't believe this is optional)

Both are extensible, so new functionality can be added to either one. (and where API limits currently exist is where proposals should come from)

It is true that PSReadLine could use more functions for managing its history, and since its persistent, should probably have more functions to manage it, since persistent storage should be managed.

I'd like to see,

• How many history items are there?
• What those history items are?
• Whether they are from the current session?
• Whether they are saved persistently?
• The get-history ID of a correlated current session history item? (or the HistoryInfo object itself)
• A way to clear the older persistent history (possibly using a filter expression?)
• Import / Export (more for additional processing)
• A way to clear the persistent history from the current session (without clearing the persistent history or preventing the current session from adding to it or searching it, and the ability to reload the persistent history on demand.

[PAStheLoD]

+1 confused user here. (On ps7.0-rc1)

It was especially strange that I saw a command in Get-History, but not in the permanent history file. Finding AddToHistoryHandler was not terribly difficult, but it took a day to finally end up here realizing that there are two history thingies. (Which is of course understandable, as one is basically the nice line editing, the other is ... something else.)

[SteveL-MSFT]

Seems that the old Windows Console binds F7 to show history and many people like this so we should see about binding that key to show history

[rkeithhill]

Keep in mind that Windows Terminal binds F7 to a dialog that enables carot browsing:

You can prevent that from coming up again by checking the "do not ask again" checkbox above.

[lzybkr]

Discussion on F7 belongs in #620

[FireInWinter]

I also think dual histories causes confusion. Especially with #searchTerm coming from the built in PowerShell history and up arrow coming from PSReadLine. That's how I originally realized there was something weird going on. I could find a command by up arrowing until I found it, but I could not find it by using #searchTerm. That was VERY counterintuitive. I eventually made a little script to search the history that works regardless if PSReadLine is loaded or not.

I just don't know why I had to write this. And yes, if PSReadLine is loaded, the script is ignoring the built in history. I think this would be a decent model moving forward. Have PSReadLine replace ALL the functionality of the built in history if it is loaded, not just make it confusing. I think it should disable the built in history, replace # completion, and overwrite Get-History. Only have the original stuff there if PSReadLine is removed. I don't see a need for 2 sets of similar code to be running. Maybe add a History Id for the current session history (so it better matches Get-History and Invoke-History).

param ([Parameter()][string]$CommandLine = '.*')

process
{
    . {
        if ( $null -ne (Get-Module -Name PSReadLine))
        {
            [Microsoft.PowerShell.PSConsoleReadLine]::GetHistoryItems()
        }
        else
        {
            Get-History -Count ([int16]::MaxValue)
        }
    } | Where-Object { $_.CommandLine -match $CommandLine} 
}