From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=FREEMAIL_FROM, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15555 invoked from network); 20 May 2020 09:39:50 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 20 May 2020 09:39:50 -0000 Received: (qmail 23357 invoked by alias); 20 May 2020 09:39:35 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 45864 Received: (qmail 11598 invoked by uid 1010); 20 May 2020 09:39:35 -0000 X-Qmail-Scanner-Diagnostics: from mout.gmx.net by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.3/25814. spamassassin: 3.4.4. Clear:RC:0(212.227.17.20):SA:0(-2.7/5.0):. Processed in 2.907198 secs); 20 May 2020 09:39:35 -0000 X-Envelope-From: markus.naeher@gmx.net X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at gmx.net designates 212.227.17.20 as permitted sender) X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Subject: Re: Feature Request: fc -C to clear history and reset counter To: zsh-workers@zsh.org References: <48e95c73-3a98-a4c2-7e0c-badf8544b4f2@gmx.net> From: =?UTF-8?Q?Markus_N=c3=a4her?= Autocrypt: addr=markus.naeher@gmx.net; keydata= mDMEXi1PPhYJKwYBBAHaRw8BAQdA5mC+PjCn5mz47ngBjY5+8r9YeloIjigNtKiHPaSlvAW0 JE1hcmt1cyBO5GhlciA8bWFya3VzLm5hZWhlckBnbXgubmV0PoiWBBMWCAA+FiEEVnCH2Hg5 cG3BryclHHm+zifSIesFAl4tTz4CGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AA CgkQHHm+zifSIeuzrQEA1dCwtJCeDcc20kPViqt5ekqidR3gpW59obGT+xvt5pgBAMyawHqH pa+PH4Mr6+9Sh/6u/yI01WwvGAK/m2CJT6sOuDgEXi1PPhIKKwYBBAGXVQEFAQEHQO2mlMor hTTZq9WUdRZMc2NhGaapZ9ZyaQesF23tQGU7AwEIB4h+BBgWCAAmFiEEVnCH2Hg5cG3Brycl HHm+zifSIesFAl4tTz4CGwwFCQlmAYAACgkQHHm+zifSIes1TQEAs2SYqsBfB++PKJIFcZdh 2xkH5YBaSN5L8hepGnb8mhgBAKZqF4jEppwZt0/c92ymZu2EssLB2WIOx+V6LazlYMkF Message-ID: <2ca16a5c-a1e9-904d-f3f6-bf785ab00343@gmx.net> Date: Wed, 20 May 2020 11:38:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US-large Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:6dNeqBMw3d0K4FW/rsdfGo3ScrYkZX7t9OQF0BLysdBw/reSNeW HRg5C1ZON6/QrHaTlg4zeo93vD9vPymw8ZDJVbd+KGGX9DYjVzcXnYPYskazX7CuhlFP9K+ rwF4QRrSoSiQRyVVNCLZeYxQdxcMOv5HglEIrZH7/XYctQglztCN9TaDAh4OnJGoV4xF33s gEB0Umkdn2ab4pdMwfAMw== X-UI-Out-Filterresults: notjunk:1;V03:K0:07ULYLvl4Hs=:4/juUGfgmV0+R2zgocT45s EjUUTY27NLSvg0oqMKLaJue0C0Emjdp9DiEKDd7/nmPv+jbxiL3IM3f9en2E8PiWn2Jg66Vyv W6urMukNxl5Wu0xQKT1I2aZaXoJFVRpm6Ie2mqQf/WhUAXqlICuSEfIcSsBZwrh+Cu1YAvXgd IcJNpIYwiMMZGR+7lK7fdwWQScYpgYRq23Dy3MvssaaODeqRjPXd5JxXF3IaaYJt94EIv+035 lDgyM2bLcszbW7ssSaeoikheYDXgnngPePAAJq/ry/N9BPF3b4qU6BdkgX6RxwqPVveU6IHQb t+qum05MGJwam26EiEwmB5QAnXxDbAbpe9vRnw1CUZ/+ab1PrJuSrOQgGVyyuRscu9HL4jbxG v07InQAPmIah/T2kizu2alZ+Gve2H9i0sH8TUhajpfBgj4ja45okCRDgCqcrCRWfmiB5jP90E E7j1flJIPoX6FrSpYT5lQhMBTJAYoUJK0lrh4a54KzLhg0QZFIvDE3zK7HFWnEGHHOnmiss9G 9GHWPS9a2mQIZywXYa9Xyx1OmqptaWE6unhN9E5CkiKqfYIcT6DWNZjYZ0wCho701KIXg8NwW iyaGTh83KRI4CJmZpGDBpT98De+BJ4fXeMadkJu5xVcoGVv8bpaxTEWwR4deyGLgkhBVbRbuw CvjUADvUS28D5cqBqpkwB60u2kg6rJL4YYF+1ZqoobE9TJXqhCE/og6C8+4XPbRFDBhUR3FyY o/132hsHMamLmMnKx69q19IB/+1+k5iYAJb4OXl7zosFfQRdxpeYr2pn4pOI5F4H6MLGB94cd pZ59sHyuWXk3L8MXkIBlkc8aFVffltWJQ5RCVS16M5lSDGDMtAw7e+qygTVmV8gwDpya/3NMU dtIEqEX1WDhAh2ppVhEiZH6vRQJHbPiFpknJ8AuYZKZ3E2YBcy38K40kHh/oAgv75PiRvMbT8 8s9VG+xeX9BdMIlBhXBQ6wnD1l6oO8wwsI3/Vb/auVLRxyrOSKgRFOo0VbVdeot0VcMq22h9g mxH75Qcwc3IVCbTg0fwddqDznBax/eLzGMeYaG6LquLAjszcbEqgELbIMXtyUL2hWmMthzf92 dmaHyJB8kD/0RphVFeFB5WtT3+XXWplKNQsegmUtjw5t+ocVC0nV9+ywsRYjLgntEGBSItvJ8 P8S38+spiUrLxtoQcQCKbErrqUie06gb5bl5YnmDNYYD2GijhjuBOJAp4rNs4TTmMcOV0cPoE uDNt/b2kQ7kXlgvIO On 20.05.20 06:15, Bart Schaefer wrote: > On Tue, May 19, 2020 at 5:27 PM Markus N=C3=A4her 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 , check the output, and if I'm happy with it, I'll do , 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 ... 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=C3=A4her wrote: >> >> I'm currently experimenting with zsh, and I copied my ~/.bash_history t= o >> ~/.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 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.