Closed donnemartin closed 8 years ago
Sounds good. Another idea is to have both our own combined history class that combines FileHistory as well the InMemoryHistory. Each command is written out to FileHistory as well as stored in InMemoryHistory.
It'd be great to also add .clearhistory command when we implement the history persistence feature.
With the new auto suggestions, this becomes more prevalent. For suggestions to be more effective I think we'd need to use a FileHistory instead of an InMemoryHistory which is persisted between sessions.
I just submitted a PR for auto-suggestions: https://github.com/awslabs/aws-shell/pull/44.
We might need special handling for the .edit command
Another idea is to have both our own combined history class that combines FileHistory as well the InMemoryHistory
For the initial public release, I'm not sure if we'll have enough time to hook up this special handling. Do you feel it's more valuable to initially ship with InMemoryHistory
or FileHistory
? IMHO I feel FileHistory
would generally be more helpful. If we decide to switch to FileHistory
it seems to be a straightforward change.
I don't have a strong preference for the initial release. This is something I hope we can address quickly after the initial release.
Hmm you're right it was really simple to have both history types. I'll send in the pull request tomorrow.
I think losing my command history after closing a session is inconvenient. It's handy to be able to use the up arrow to cycle through previous commands.
With the new auto suggestions, this becomes more prevalent. For suggestions to be more effective I think we'd need to use a
FileHistory
instead of anInMemoryHistory
which is persisted between sessions. Another option is to hook up to something more general like.bash_history
.We might need special handling for the
.edit
command if we switch toFileHistory
as that could load a ton of history--maybe onaws-shell
startup we can tag where we are in the history and only load from that checkpoint.