zsh-workers
 help / color / Atom feed
* 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 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 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 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 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-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-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  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

* 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-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

end of thread, back to index

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

zsh-workers

Archives are clonable: git clone --mirror http://inbox.vuxu.org/zsh-workers

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.workers


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git