* Feature Request: fc -C to clear history and reset counter @ 2020-05-19 15:52 Markus Näher 2020-05-19 18:28 ` Roman Perepelitsa 2020-05-19 22:33 ` Bart Schaefer 0 siblings, 2 replies; 15+ messages in thread From: Markus Näher @ 2020-05-19 15:52 UTC (permalink / raw) To: zsh-workers Hi, I'm planning to switch to zsh. There's one thing missing that currently keeps me from finally leaving bash behind: I'm using multiple individually curated histories for my projects. This keeps the history short and clear. One history (my "default" history) is for my non-project-related day-to-day tasks. With bash, I usually do cd /path/to/my/project/; history -c; history -r project_bash_history and I even set HISTFILE= to prevent writing to the history when I exit the shell. Of course, I sometimes need to add desired commands to the history file manually. That's what I mean by "curated history". I've learned that the corresponding zsh command is "fc". It has -R (and -W), but it's missing -C for clearing the history completely. I've found some hints to temporarily set HISTSIZE=0. Indeed, it empties the history, but it does not reset the counter. So if the history had 137 entries, the new history will start at 138. One advantage of my curated histories is that I know the numbers of my most important entries. But they will get useless when they shift and the amout is always different. To me, a -C option in fc would be very helpful. Or maybe even -C -R to clear and read in one call, but this would be bonus. :-) Thanks and Regards, Markus ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Feature Request: fc -C to clear history and reset counter 2020-05-19 15:52 Feature Request: fc -C to clear history and reset counter Markus Näher @ 2020-05-19 18:28 ` Roman Perepelitsa 2020-05-19 20:22 ` Markus Näher 2020-05-19 22:33 ` Bart Schaefer 1 sibling, 1 reply; 15+ messages in thread From: Roman Perepelitsa @ 2020-05-19 18:28 UTC (permalink / raw) To: Markus Näher; +Cc: Zsh hackers list On Tue, May 19, 2020 at 5:53 PM Markus Näher <markus.naeher@gmx.net> wrote: > but it's missing -C for clearing the history completely. Why not restart zsh with `exec zsh`? Roman. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Feature Request: fc -C to clear history and reset counter 2020-05-19 18:28 ` Roman Perepelitsa @ 2020-05-19 20:22 ` Markus Näher 2020-05-19 22:58 ` Bart Schaefer 2020-05-19 23:03 ` Daniel Shahaf 0 siblings, 2 replies; 15+ messages in thread From: Markus Näher @ 2020-05-19 20:22 UTC (permalink / raw) To: zsh-workers On 19.05.20 20:28, Roman Perepelitsa wrote: > On Tue, May 19, 2020 at 5:53 PM Markus Näher <markus.naeher@gmx.net> wrote: >> but it's missing -C for clearing the history completely. > > Why not restart zsh with `exec zsh`? > > Roman. > And how do I load the project-specific history (and _only_ that one) in the new instance ? The new instance will execute all startup scripts (and that's OK because of all other things like themes, settings, aliases, ...) and load the "default" history. So I still can not have the new history _without_ the "default" history but counter starting at 1. This means I'm in the same situation again. I have a second use case for clearing the history. I only started my request with the use case that's easier to explain. For bash, I wrote a function that allows me to edit the _whole_ history (not only the last entry like fc), even reorder entries. This is it: history_edit() { if [ "${EDITOR}" == "" ] then echo "EDITOR must be set." return 1 fi tempdir="/tmp/${USER}" tempfile="/tmp/${USER}/bash_history.$$" if [ ! -d "${tempdir}" ] then mkdir -p "${tempdir}" chmod 770 "${tempdir}" fi history -w "${tempfile}" ${EDITOR} "${tempfile}" history -c history -r "${tempfile}" rm -f "${tempfile}" } I just cannot work without that. All of my working style is adapted to having that option. Markus ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Feature Request: fc -C to clear history and reset counter 2020-05-19 20:22 ` Markus Näher @ 2020-05-19 22:58 ` Bart Schaefer 2020-05-20 0:13 ` Markus Näher 2020-05-20 0:23 ` Markus Näher 2020-05-19 23:03 ` Daniel Shahaf 1 sibling, 2 replies; 15+ messages in thread From: Bart Schaefer @ 2020-05-19 22:58 UTC (permalink / raw) To: Markus Näher; +Cc: zsh-workers On Tue, May 19, 2020 at 1:22 PM Markus Näher <markus.naeher@gmx.net> wrote: > > I have a second use case for clearing the history. I only started my > request with the use case that's easier to explain. > > For bash, I wrote a function that allows me to edit the _whole_ history > (not only the last entry like fc), even reorder entries. > > I just cannot work without that. All of my working style is adapted to > having that option. There's no reason you can't do that in zsh, but you're going to have some potential issues. I've written about this in a zsh-users thread within the last couple of months. Copy-pasting from that thread ... The only safe way to directly edit the history is to make sure no other zsh is running that might rewrite it, and then set SAVEHIST=0 in your current shell before doing anything else. (You can also do this by "fc -p" before invoking the editor, now that I think of it.) Once you are sure you have done that, then it should be OK to use an editor on the history file. Be aware that multi-line events (such as "for" or "while" loops) are stored with lines terminated by backslash, so if you start deleting a line that ends in backslash you need to also delete all the adjacent lines that end in backslash, up to and including the next following line that does NOT end in a backslash. Single-line events never contain a trailing backslash. If you are using any of the setopts that store timestamped history entries, each event will be prefixed by a ":" command that ends at the next ";", with the timestamp between. You should delete these along with the event you want to remove, and avoid altering any that are on other event lines. Something I forgot to mention in that other thread is that the zsh history file is stored in what's called "metafied" format. Mikael Magnusson posted an "unmetafy.c" program back in 2015 which you should be able to find by a search of the zsh-users archives (subject: "Read file with escaped newlines into array"). ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Feature Request: fc -C to clear history and reset counter 2020-05-19 22:58 ` Bart Schaefer @ 2020-05-20 0:13 ` Markus Näher 2020-05-20 0:23 ` Markus Näher 1 sibling, 0 replies; 15+ messages in thread From: Markus Näher @ 2020-05-20 0:13 UTC (permalink / raw) To: zsh-workers On 20.05.20 00:58, Bart Schaefer wrote: > On Tue, May 19, 2020 at 1:22 PM Markus Näher <markus.naeher@gmx.net> wrote: >> >> I have a second use case for clearing the history. I only started my >> request with the use case that's easier to explain. >> >> For bash, I wrote a function that allows me to edit the _whole_ history >> (not only the last entry like fc), even reorder entries. >> >> I just cannot work without that. All of my working style is adapted to >> having that option. > > There's no reason you can't do that in zsh, but you're going to have > some potential issues. I've written about this in a zsh-users thread > within the last couple of months. > > Copy-pasting from that thread ... > > The only safe way to directly edit the history is to make sure no > other zsh is running that might rewrite it, and then set SAVEHIST=0 in > your current shell before doing anything else. (You can also do this > by "fc -p" before invoking the editor, now that I think of it.) > > Once you are sure you have done that, then it should be OK to use an > editor on the history file. Be aware that multi-line events (such as > "for" or "while" loops) are stored with lines terminated by backslash, > so if you start deleting a line that ends in backslash you need to > also delete all the adjacent lines that end in backslash, up to and > including the next following line that does NOT end in a backslash. > Single-line events never contain a trailing backslash. > > If you are using any of the setopts that store timestamped history > entries, each event will be prefixed by a ":" command that ends at the > next ";", with the timestamp between. You should delete these along > with the event you want to remove, and avoid altering any that are on > other event lines. > > Something I forgot to mention in that other thread is that the zsh > history file is stored in what's called "metafied" format. Mikael > Magnusson posted an "unmetafy.c" program back in 2015 which you should > be able to find by a search of the zsh-users archives (subject: "Read > file with escaped newlines into array"). Yes, I'm aware of the multi-write issues. That's why I'm setting HISTFLE= in bash, which corresponds to SAVEHIST=0. I even plan to add SAVEHIST=0 to my .zshrc. I never want my curated files to be overwritten. I think I need to clarify that my history_edit bash function does not edit the history file. By writing it to a temp file, clearing and reading that file, I edit the _local_ history of the shell I'm currently in, and other shells are unaffected, which is also important to me. In fact, I mostly have at least 5 open shells. That's why I added the .$$ (PID of the shell) to the temp filename, so I can even do history_edit in all shells without interfering. I only edit the history files when I do my curating. As my histories are fairly mature, this does not occur very often. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Feature Request: fc -C to clear history and reset counter 2020-05-19 22:58 ` Bart Schaefer 2020-05-20 0:13 ` Markus Näher @ 2020-05-20 0:23 ` Markus Näher 1 sibling, 0 replies; 15+ messages in thread From: Markus Näher @ 2020-05-20 0:23 UTC (permalink / raw) To: zsh-workers On 20.05.20 00:58, Bart Schaefer wrote: > On Tue, May 19, 2020 at 1:22 PM Markus Näher <markus.naeher@gmx.net> wrote: >> >> I have a second use case for clearing the history. I only started my >> request with the use case that's easier to explain. >> >> For bash, I wrote a function that allows me to edit the _whole_ history >> (not only the last entry like fc), even reorder entries. >> >> I just cannot work without that. All of my working style is adapted to >> having that option. > > There's no reason you can't do that in zsh, but you're going to have > some potential issues. I've written about this in a zsh-users thread > within the last couple of months. > > Copy-pasting from that thread ... > > The only safe way to directly edit the history is to make sure no > other zsh is running that might rewrite it, and then set SAVEHIST=0 in > your current shell before doing anything else. (You can also do this > by "fc -p" before invoking the editor, now that I think of it.) > > Once you are sure you have done that, then it should be OK to use an > editor on the history file. Be aware that multi-line events (such as > "for" or "while" loops) are stored with lines terminated by backslash, > so if you start deleting a line that ends in backslash you need to > also delete all the adjacent lines that end in backslash, up to and > including the next following line that does NOT end in a backslash. > Single-line events never contain a trailing backslash. > > If you are using any of the setopts that store timestamped history > entries, each event will be prefixed by a ":" command that ends at the > next ";", with the timestamp between. You should delete these along > with the event you want to remove, and avoid altering any that are on > other event lines. > > Something I forgot to mention in that other thread is that the zsh > history file is stored in what's called "metafied" format. Mikael > Magnusson posted an "unmetafy.c" program back in 2015 which you should > be able to find by a search of the zsh-users archives (subject: "Read > file with escaped newlines into array"). One thing I forgot to mention in my previous reply: I'm currently experimenting with zsh, and I copied my ~/.bash_history to ~/.histfile. At least, zsh can read the history in plaintext. So as long as I never let zsh write this file, I can keep on selectively adding commands there with the editor. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Feature Request: fc -C to clear history and reset counter 2020-05-19 20:22 ` Markus Näher 2020-05-19 22:58 ` Bart Schaefer @ 2020-05-19 23:03 ` Daniel Shahaf 2020-05-19 23:17 ` Bart Schaefer 2020-05-21 3:37 ` Daniel Shahaf 1 sibling, 2 replies; 15+ messages in thread From: Daniel Shahaf @ 2020-05-19 23:03 UTC (permalink / raw) To: Markus Näher; +Cc: zsh-workers Markus Näher wrote on Tue, 19 May 2020 22:22 +0200: > On 19.05.20 20:28, Roman Perepelitsa wrote: > > On Tue, May 19, 2020 at 5:53 PM Markus Näher <markus.naeher@gmx.net> wrote: > >> but it's missing -C for clearing the history completely. > > > > Why not restart zsh with `exec zsh`? > > > > Roman. > > > > And how do I load the project-specific history (and _only_ that one) in > the new instance ? > There are plugins out there that provide per-directory history for zsh. Have you seen them? > The new instance will execute all startup scripts (and that's OK because > of all other things like themes, settings, aliases, ...) and load the > "default" history. > So I still can not have the new history _without_ the "default" history > but counter starting at 1. This means I'm in the same situation again. Yes, «exec zsh» is a bit of a sledgehammer. > For bash, I wrote a function that allows me to edit the _whole_ history > (not only the last entry like fc), even reorder entries. This is it: > > history_edit() { ⋮ > } > > I just cannot work without that. All of my working style is adapted to > having that option. I thought we might be able to present the history as a magic variable (like $aliases). With this, you'd be able to reset the history (by assigning to the variable), edit the history (with vared + edit-command-line), etc.. This would also sidestep some of the serialization issues Bart describes in his reply. Also, we should probably make vared emit array elements one per line, shouldn't we? That seems to be just: diff --git a/Src/Zle/zle_main.c b/Src/Zle/zle_main.c index 8c0534708..53ecaed63 100644 --- a/Src/Zle/zle_main.c +++ b/Src/Zle/zle_main.c @@ -1767,7 +1767,7 @@ bin_vared(char *name, char **args, Options ops, UNUSED(int func)) *tptr++ = *aptr; /* No, keep original array element */ } *tptr = NULL; - s = sepjoin(tmparr, NULL, 0); + s = sepjoin(tmparr, "\n", 0); } else { s = ztrdup(getstrvalue(v)); } Cheers, Daniel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Feature Request: fc -C to clear history and reset counter 2020-05-19 23:03 ` Daniel Shahaf @ 2020-05-19 23:17 ` Bart Schaefer 2020-05-21 3:37 ` Daniel Shahaf 1 sibling, 0 replies; 15+ messages in thread From: Bart Schaefer @ 2020-05-19 23:17 UTC (permalink / raw) To: zsh-workers On Tue, May 19, 2020 at 4:04 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > > There are plugins out there that provide per-directory history for zsh. I had meant to mention that, too, but got distracted by searching for the "unmeta.c" program ... > I thought we might be able to present the history as a magic variable > (like $aliases). Yeah, that turns out to be REALLY messy, which is why $history is a read-only hash table indexed on event number. > Also, we should probably make vared emit array elements one per line, > shouldn't we? Hrrrm, I think I'd rather that were an option rather than the default. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Feature Request: fc -C to clear history and reset counter 2020-05-19 23:03 ` Daniel Shahaf 2020-05-19 23:17 ` Bart Schaefer @ 2020-05-21 3:37 ` Daniel Shahaf 1 sibling, 0 replies; 15+ messages in thread From: Daniel Shahaf @ 2020-05-21 3:37 UTC (permalink / raw) To: zsh-workers Daniel Shahaf wrote on Tue, 19 May 2020 23:03 +0000: > Also, we should probably make vared emit array elements one per line, > shouldn't we? That seems to be just: «IFS=$'\n' vared» does the trick too. (Thanks Bart for reminding me.) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Feature Request: fc -C to clear history and reset counter 2020-05-19 15:52 Feature Request: fc -C to clear history and reset counter Markus Näher 2020-05-19 18:28 ` Roman Perepelitsa @ 2020-05-19 22:33 ` Bart Schaefer 2020-05-20 0:13 ` Markus Näher 1 sibling, 1 reply; 15+ messages in thread From: Bart Schaefer @ 2020-05-19 22:33 UTC (permalink / raw) To: Markus Näher; +Cc: zsh-workers On Tue, May 19, 2020 at 8:53 AM Markus Näher <markus.naeher@gmx.net> wrote: > > I'm using multiple individually curated histories for my projects. This > keeps the history short and clear. One history (my "default" history) is > for my non-project-related day-to-day tasks. > > I've learned that the corresponding zsh command is "fc". It has -R (and > -W), but it's missing -C for clearing the history completely. Zsh has what I think is potentially a superior mechanism: fc -p / fc -P to push and pop the history, respectively. fc -p creates a new empty history, resetting the counter fc -P discards the pushed history (if any) and restores the previous one So you can simulate bash's "history -c" by "fc -P;fc -p", with some appropriate extra arguments to manipulate history sizes and file locations. It should even work to do "fc -p" in your .zshrc file so that the "default" history is always empty and The initial read of the history file goes into a pushed history. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Feature Request: fc -C to clear history and reset counter 2020-05-19 22:33 ` Bart Schaefer @ 2020-05-20 0:13 ` Markus Näher 2020-05-20 4:15 ` Bart Schaefer 0 siblings, 1 reply; 15+ messages in thread From: Markus Näher @ 2020-05-20 0:13 UTC (permalink / raw) To: zsh-workers On 20.05.20 00:33, Bart Schaefer wrote: > On Tue, May 19, 2020 at 8:53 AM Markus Näher <markus.naeher@gmx.net> wrote: >> >> I'm using multiple individually curated histories for my projects. This >> keeps the history short and clear. One history (my "default" history) is >> for my non-project-related day-to-day tasks. >> >> I've learned that the corresponding zsh command is "fc". It has -R (and >> -W), but it's missing -C for clearing the history completely. > > Zsh has what I think is potentially a superior mechanism: fc -p / fc > -P to push and pop the history, respectively. > > fc -p creates a new empty history, resetting the counter > fc -P discards the pushed history (if any) and restores the previous one > > So you can simulate bash's "history -c" by "fc -P;fc -p", with some > appropriate extra arguments to manipulate history sizes and file > locations. > > It should even work to do "fc -p" in your .zshrc file so that the > "default" history is always empty and > The initial read of the history file goes into a pushed history. I would not call any of these concepts superior to the other. Different people just prefer different things. 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. :-) Can you give me some advice about the "appropriate extra arguments" you wrote about ? My goal is to really start over, having nothing left from the previous history. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Feature Request: fc -C to clear history and reset counter 2020-05-20 0:13 ` Markus Näher @ 2020-05-20 4:15 ` Bart Schaefer 2020-05-20 9:38 ` Markus Näher 2020-05-20 23:53 ` Bart Schaefer 0 siblings, 2 replies; 15+ messages in thread From: Bart Schaefer @ 2020-05-20 4:15 UTC (permalink / raw) To: Markus Näher; +Cc: zsh-workers On Tue, May 19, 2020 at 5:27 PM Markus Näher <markus.naeher@gmx.net> wrote: > > On 20.05.20 00:33, Bart Schaefer wrote: > > > > So you can simulate bash's "history -c" by "fc -P;fc -p", with some > > appropriate extra arguments to manipulate history sizes and file > > locations. > > I would not call any of these concepts superior to the other. Different > people just prefer different things. As you like. I just think it's easier to create multiple independent saved histories with "fc -p" than with "history -c" plus modifying a bunch of global variables. > 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. > Can you give me some advice about the "appropriate extra arguments" you > wrote about ? My goal is to really start over, having nothing left from > the previous history. 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. On Tue, May 19, 2020 at 5:29 PM Markus Näher <markus.naeher@gmx.net> 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Feature Request: fc -C to clear history and reset counter 2020-05-20 4:15 ` Bart Schaefer @ 2020-05-20 9:38 ` Markus Näher 2020-05-21 1:05 ` Bart Schaefer 2020-05-20 23:53 ` Bart Schaefer 1 sibling, 1 reply; 15+ messages in thread From: Markus Näher @ 2020-05-20 9:38 UTC (permalink / raw) To: zsh-workers On 20.05.20 06:15, Bart Schaefer wrote: > On Tue, May 19, 2020 at 5:27 PM Markus Näher <markus.naeher@gmx.net> 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@gmx.net> 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Feature Request: fc -C to clear history and reset counter 2020-05-20 9:38 ` Markus Näher @ 2020-05-21 1:05 ` Bart Schaefer 0 siblings, 0 replies; 15+ messages in thread From: Bart Schaefer @ 2020-05-21 1:05 UTC (permalink / raw) To: Markus Näher; +Cc: zsh-workers On Wed, May 20, 2020 at 2:39 AM Markus Näher <markus.naeher@gmx.net> wrote: > > 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. It's harmless to pop when nothing has been pushed, so you can just do history_c() { fc -P ; fc -p } Then stick that in your current bash usage pattern wherever you have "history -c" and go on your merry way. You'll always have exactly one extra "depth" of history. However, there is probably more you can do if you're interested in digging into it. > 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. The "fc -I" (dash capital eye, for those in sans serif) can be used to select only the commands that were entered interactively, if that is helpful. That is, it excludes any commands read from a history file, whether at startup, or with "fc -R filename" or "fc -p filename". (There is not presently an inverse of this.) > You wrote that pop will save back the project history file. That's also > something I'd like to prevent. This can be done by changing/unsetting HISTFILE, or zeroing SAVEHIST, after "fc -p". > **My curated history files are sacred. No one but me should write them.** Why not keep them "chmod -w" and only make them writable during editing? > 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). Zsh additionally has histignorealldups, but I don't think it works the way you want. However, you might take a look at the zshaddhistory hook function, and the HISTORY_IGNORE variable. > **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.** Does this mean that you are always clearing the history, editing the file, and then reloading from the file? Thus in each of the two or three shells that you start to enter a project, your edit begins from whatever you saved in the previous shell? I was thinking about what Daniel said about using vared on the history, to edit it within the shell rather than in a disk file. There might be a way to simulate that in shell code, using "fc -p" to install the edited events. Hmm. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Feature Request: fc -C to clear history and reset counter 2020-05-20 4:15 ` Bart Schaefer 2020-05-20 9:38 ` Markus Näher @ 2020-05-20 23:53 ` Bart Schaefer 1 sibling, 0 replies; 15+ messages in thread From: Bart Schaefer @ 2020-05-20 23:53 UTC (permalink / raw) To: zsh-workers On Tue, May 19, 2020 at 9:15 PM Bart Schaefer <schaefer@brasslantern.com> wrote: > > Bash stores its history file as essentially a > shell script, and loads it by parsing it as script input but skipping > execution. It has been pointed out to me that this is incorrect and misleading; bash does not use its shell language parser to reload the history, which if I had thought for half a moment is obvious because bash uses the readline library. I was trying to make an analogy to emphasize that bash history is typically formatted as directly-executable shell commands whereas zsh history is frequently not so, and I botched it. Sorry. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2020-05-21 3:38 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-19 15:52 Feature Request: fc -C to clear history and reset counter Markus Näher 2020-05-19 18:28 ` Roman Perepelitsa 2020-05-19 20:22 ` Markus Näher 2020-05-19 22:58 ` Bart Schaefer 2020-05-20 0:13 ` Markus Näher 2020-05-20 0:23 ` Markus Näher 2020-05-19 23:03 ` Daniel Shahaf 2020-05-19 23:17 ` Bart Schaefer 2020-05-21 3:37 ` Daniel Shahaf 2020-05-19 22:33 ` Bart Schaefer 2020-05-20 0:13 ` Markus Näher 2020-05-20 4:15 ` Bart Schaefer 2020-05-20 9:38 ` Markus Näher 2020-05-21 1:05 ` Bart Schaefer 2020-05-20 23:53 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).