Repository navigation
A more intelligent & useful history file & way to query it #1886
Description
It would be great to have a much more intelligent & complex history file than the current simple implementation that we currently have, although to achieve this I expect that it would likely be much more computationally expensive than the current implementation.
Ideally I would like to see this be more structured & complex and able to be queried in a way that allows for much better analytics of common command use that enables inspection on the count of use being aliased or using the full command name, common parameter combinations as well as a count of the use of each parameter & arguments to that parameter.
Loose inital release goals
- Wrapped in a module scoped experimental feature
- API based with a end data store provider plugin module (allows SQLite, CosmosDb, jsonFile etc)
- use of SqlLite file (local or remote) - Default option
- Local File created if not already there
- Initial base DB Schema
- Ideally Encrypted
Post release enhancements
- User Extensibility of DB Schema
- Preference of remote for cross machine history reasons) - Configurable option
- Configuration options
- current file
- other remote sources
- Additional Querying cmdlets to replace needing to use Group|Sort cmdlets etc
- Plugin with AIShell & other tooling
Activity
lzybkr commentedon Oct 16, 2020
Cross session sharing makes this somewhat hard to implement without a proper database.
I see sqlite might be a reasonable option.
daxian-dbw commentedon Oct 30, 2020
The suggestion to use
Frecencyalgorithm for history prediction (#1808) and also possibly a local ML model to provide predictions from the history patterns would also require a more powerful storage for history. So yes, we can look into replacing the history file withsqlite.kilasuit commentedon Apr 10, 2023
Dongbo Wang (@daxian-dbw) This still would be a big win for PSReadline going forward and it would be great if you and I could find some time together to make it happen
daxian-dbw commentedon Apr 10, 2023
I have been wanting to do this, but it just couldn't get in the priority cut due to the limited team resources.
Steven Bucher (@StevenBucher98) has put this in the 2.3.0 release consideration, and hopefully we will get commitment for this one.
By the way, the
Microsoft.Data.Sqlitepackage looks a good fit for this work.kilasuit commentedon Apr 10, 2023
I realise it's not a smallish bit of work to implement especially the more I think about additional configurability options we may want to add. Let me try and carve out some time properly going forward so that I can be of use here (starting with me actually writing some C# after a long long time saying I want to!)
StartAutomating commentedon Apr 10, 2023
This looks interesting.
I tackled some of the requests in a proof-of-concept module I made a bit back: https://github.com/StartAutomating/PowerHistory
I'd hope that one of these days, we'd be more willing to accept PowerShell contributions to the PowerShell language.
claudio-salvio commentedon Apr 10, 2023
Dongbo Wang (@daxian-dbw)
Perhaps it would be better if both persistence mechanisms were available and users could decide which one to use according to their preference or need.
StartAutomating commentedon Apr 10, 2023
Maybe, and this might just be crazy talk here, but maybe one could store persistent history in a vault (rather than reinvent a wheel here)
kilasuit commentedon Apr 10, 2023
ClauS (@claudio-salvio) This is something that I would look to have as configurable by user with a preference to use the sqlite by default (or other remote db option) but not remove it until a major version if any available module use metrics shows a mass switchover from current implementation.
kilasuit commentedon Apr 10, 2023
I feel that this would be a goal for the longer term but feel that this is loosely captured under configurability options
lzybkr commentedon Sep 2, 2023
I'd always sort of intended on implementing something here, I'd been thinking about it before this issue was opened.
There are now some options that work across shells. I've been using atuin and it's meeting my needs for now.
kilasuit commentedon Aug 2, 2025
Dongbo Wang (@daxian-dbw)
I've been thinking of this again as the current implementation has been bugging me a fair bit recently as the lack of metadata in the txt file, which could be a different & perhasps quicker way to do what I would like for this, though I do stil think that using a db for storage makes the most sense.
This likely will makes sense being an experimental feature in PSReadline when we do implement it for a few releases so that we can gauge how well used it ends up.
One of my concerns is using an on disk sqlite db is we should really encrypt it by default, however that adds overhead so would need to in the implementation have it so that the db encryption is configurable as an opt-out.
daxian-dbw commentedon Aug 4, 2025
Justin Chung (@jshigetomi) has been working on a prototype using sqlite database for history store.
kilasuit commentedon Oct 1, 2025
Would be good as well for there to be a way to inject existing PSReadLine history files into this store for a GA Release of this feature.