Re: An example of writing a custom history file?

[Rocky Bernstein <rocky.bernstein@xxxxxxxxx>]

On Mon, Dec 15, 2014 at 1:26 PM, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
wrote:

> On Dec 15, 12:05pm, Rocky Bernstein wrote:
> }
> } Making the change suggested, adding 1000 doesn't change the behavior - no
> } file is written. Again, here is the entire 12-line program:
> }
> }     #!/usr/bin/zsh
> }     fc -ap /tmp/example_history 1000
> }
> }     local line
> }     # Read lines and add them to history
> }     while vared -h -p "hey: " line
> }     do
> }         [[ $line == 'quit' ]] && exit 0
> }         # The -s option below adds the line to the history
> }         print -s $line
> }         line=''
> }     done
>
> This worked for me exactly as written; I got lines saved in the
> /tmp/example_history file.  However, I was working with an interactive
> shell, which normally saves history at exit.  If you are trying to run
> this as a stand-alone script, you probably don't want "exit 0" there.
> More likely you just want to "break" and let the loop finish.  Also
> if running standalone, there's no "function scope" so I suspect that
> foils the usual action of "fc -a".
>
> Try it like this:
>
>     fc -ap /tmp/example_history 1000 1000
>
>     local line
>     # Read lines and add them to history
>     while vared -h -p "hey: " line
>     do
>         [[ $line == 'quit' ]] && break
>         # The -s option below adds the line to the history
>         # The -R option avoids other "print" processing
>         print -sR $line
>         line=''
>     done
>     # Save/pop the pushed history
>     fc -P
>
> You might also try adding
>
>     setopt localoptions incappendhistory
>
> so that the lines are written to the file as soon as "print -s" adds
> them, rather than waiting for the "fc -P".
>

Tried that. Several times, several places, several ways. It didn't work,
and I
am at my frustration level where I don't want to pursue it. If someone else
does, great.  I appreciate the suggestion and your help though.


} When the basic history mechanism isn't working, it doesn't help to pour
> } over a 138-line program that performs several functions in one program,
> } adds key bindings, beeps at the terminal, has color themes, and uses some
> } sort of "{ } aways { }" construct that probably is a Zsh extension and
> not
> } POSIX shell construct.
>
> You asked to be pointed at an example; I can't point to something that
> doesn't exist, so I pointed to something that does.
>

Sure, that's better than nothing. My larger point is that although I
realize and appreciate
the enormous effort that has been put into documenting zsh, the bottom line
is that too often for me it doesn't work all that well. One reason is a
myriad
of complicated details often specific to zsh rather than some simple basic
examples to start with before giving pointers to where you can get more
detailed
information.

I see there is http://zshwiki.org. Perhaps I'll put this little example on
that.



>
> However, if you're writing a zsh debugger, presumably you need to know
> about and potentially use zsh extensions?
>

Again this misses the point. I could roughly understand what's going there.
As I mentioned with variable interpolation, it's just a distraction if when
suggested
for the pedagogical purpose of understanding how command history works.

The debugger itself, yes, it does have to be aware of zsh extensions. To a
good
extent the zsh interpreter handles that. It will step into blocks and report
where it is and so on.

But as for the coding, I have written 3 POSIX shell debuggers. So the more
I can
just stick to POSIX the more code can be shared among the 3 debuggers.

But in closing, again, thanks for the help.