The in memory and persistent history is confusing, persistent should be the default behaviour

Challenges
1

Referencing the history and history persistence extensions.
This is in reference to the issue raised earlier - Tests are dependent on each other
I was facing the same issue, I actually implemented it with persistent memory by get go and it breaks the listing test because it expects a fresh history file. This is not what would have happened in a real shell.

History default behaviour should be in persistent memory file only, maintaining in memory history then adding it to a persistent history does not mimick real shells and it’s super confusing to work on it this way.
These two extensions should be merged into one always keeping persistent memory in mind.
This is my opnion, would love to know if someone else feels the same and maintainers’ thoughts.

Now I will proabably have to remove my persistent implementation, to a more primitive in memory one just to pass history extension and then introduce a file later to pass the history persistence extension. This pattern although seems to be intended for incremental learning, but in reality is not mimicking the shell behaviour at all.

2

We do try to mimic real shells as much possible (we run our tester against common shells to ensure this), so I’d be surprised if we’re actually testing behavior that isn’t the same as what common shells do.

@andy1li will do a deeper dive and report back on this though!

4

“maintaining in memory history then adding it to a persistent history does not mimick real shells.”
I realise this statement and my other claims to know how real shells handle history are false.
Apparently shells always maintain in memory and write to histfile on exit.
I guess then we could improve the instructions to explictly mention when we need a persistent memeory and when we need it in memory to help unaware people like me who assume the history is always persistent.