Re: Feature Request: fc -C to clear history and reset counter

[Markus Näher <markus.naeher@xxxxxxx>]

On 20.05.20 06:15, Bart Schaefer wrote:
> On Tue, May 19, 2020 at 5:27 PM Markus Näher <markus.naeher@xxxxxxx> wrote:
>
>> I've read about the push/pop feature, but I'm more the "throw away the
>> old stuff and start over" kind of guy. I'll never need to pop. :-)
>
> You'd pop just to keep the shell from continually consuming more
> memory.  Truly clearing the history is pop followed by push; pushing
> is just hiding the old history.

Keeping the shell from continually consuming more memory is one of the
reasons why I hesitate to use push when I know I never will pop.



> I don't know your exact use pattern, but let's say for the sake of
> example that you have 100 commands in your never-overwritten
> ~/.histfile, but you never want to save more than 20 commands in a
> given per-project history file.  On entering the shell, your 100 saved
> commands get loaded in.
>
> Now you're entering your project, which has its history in
> $PWD/.project_history (for example).  If for example upon "cd" into
> the project directory, you run
>   fc -p $PWD/.project_history 20 20
> that will load the .project_history file and automatically set the
> HISTFILE, HISTSIZE, and SAVEHIST variables so that when you next
> execute "fc -P" (presumably, when leaving the directory again) it will
> save the most recent 20 commands back to the .project_history file,
> reset the history to those original 100 commands, and restore the old
> values of the variables.
>
> You can modify this behavior by passing only the file name, or the
> file name and one number, or none of those.

My usage pattern is even more complex. I's heavily based on making a
difference between the commands loaded from my curated history files and
the "local" or "transient" history while running the shell. I put way
more effort in preparing things, then using them will be easier.

You wrote that pop will save back the project history file. That's also
something I'd like to prevent. The project history files are even more
important to never be overwritten than the "default" history file in ~.

**My curated history files are sacred. No one but me should write them.**

Here is my usage pattern:

As I wrote, I rarely add commands to my history file(s). But I do
history_edit very, very, very often.

I'm a lazy person, especially on the keyboard. I'd like to type as few
as possible. And I also like a static working environment. Not static
forever, but static while I'm in a specific task.

To achieve the laziness and staticness, I use (or abuse if you want) the
history-related behavior of the shell:
All of the entries in my history files start with a blank. So a command
never gets duplicated to the bottom when I recall it, but recalling
works despite the blank. (The igonoredups/ignoreboth in bash seems to
work only on consecutive duplicates).
I even have grouped the entries in my history files by comments.

I have lots of regular tasks to do. When working on a project. I mostly
have multiple shells open. Let's say it is a development project and I'm
running it locally for testing my new stuff. This is a simplified example:
Shell 1 is for build/deploy/run, shell 2 for searching things in the
logs, shell 3 for other monitoring stuff, ...

I do more things than just cd /path/to/project and load the project
history. **In every shell, the first thing I do is history_edit and
rearrange the order of the entries so that the commands I need for this
task are at the bottom.**
This way, I always have the needed commands directly at hand.
I only need to do <cursor up><enter>, check the output, and if I'm happy
with it, I'll do <up><up><enter>, and so on. The leading blanks ensure
that e.g. the second last command is always the same within this shell
(locally static).

This rearrangement of the history order is BTW a reason why I can't use
shared histories.

Of course, I'm also doing new things while working in a project. Often,
I'll have to try different variations of a command until I get the
desired result. I'm doing that **without** leading blank, so the
commands **are** added to the "local" history. After that, I do
history_edit again to eliminate all the failed attempts an only keep the
successful final one. Sometimes at the bottom, sometimes I move it up a
few lines. This gives me shorter <up>...<up><enter> sequences.
And sometimes I add this new command to my curated history.

**I hope this makes clear that history_edit is a completely normal thing
for me to do. Sometimes every few minutes. Having to deal with push/pop
will make this much more complicated as I have to keep track if and how
many times I have pushed.**



> On Tue, May 19, 2020 at 5:29 PM Markus Näher <markus.naeher@xxxxxxx> wrote:
>>
>> I'm currently experimenting with zsh, and I copied my ~/.bash_history to
>> ~/.histfile. At least, zsh can read the history in plaintext.
>
> Careful with that, too.  Bash stores its history file as essentially a
> shell script, and loads it by parsing it as script input but skipping
> execution.  Zsh stores its history file more like text intended to be
> consumed by the "read" builtin, and loads it straight back into the
> internal history structure without passing it through the shell
> language parser.  That means that multi-line commands in the bash
> history will become multiple, separately-numbered events in the zsh
> history.  If all your curated events are one-liners, this won't
> matter.

I have many multi-liners in my histories, but of course they all are
converted to one-liners with semicolons. In bash, if you execute a
multi-liner and do <cursor up> afterwards, you already have it
converted. I just tested it ... zsh keeps it multilined. It's definitely
easier to read, but for my purpose, I will need to convert them
manually. That's OK for me.