Re: turn off history

[Tomas Hlavaty]

On Wed 27 Jul 2022 at 18:35, Bernd Paysan <bernd@net2o.de> wrote:
> Am Mittwoch, 27. Juli 2022, 13:13:08 CEST schrieb Anton Ertl:
>> On Wed, Jul 27, 2022 at 01:00:37PM +0200, Bernd Paysan wrote:
>> > Another question is: Should we open the history file later in the boot
>> > process, e.g. on entering interactive mode?  There's no need to do that
>> > earlier.
>> I have been thinking about having a word INTERACTIVE-COLD or somesuch,
>> used like 'COLD, but only invoked when enterin interactive mode, but
>> have not acted (yet).
>
> There are two hooks where to put things that get called when you enter 
> interactive state.  The first one is BOOTMESSAGE, the second is 'QUIT.  We 
> have 
> put LOAD-RC into BOOTMESSAGE, so maybe that is the right place to initialize 
> the interactive state.  I would open the history last (after the boot message 
> is displayed).

It would be great, if it was possible to turn off history not from
outside using GFORTHHIST environment variable but somehow from inside
forth.

My server.fs looks roughly like this:

s" gforth" environment? [IF]
  ' noop IS bootmessage
  \ ' noop IS 'cold \ still uses history file
  warnings off
  -status
[THEN]
\ some code
s" gforth" environment? [IF]
  :noname serve bye ; is 'quit
[ELSE]
  serve
[THEN]
\ EOF

' noop IS bootmessage   does not turn the history off.
' noop IS 'cold   does not turn the history off either.

I do not understand why setting bootmessage to noop from inside the
script turns the bootmessage off but setting 'cold to noop from inside
the script does not turn the history off.  Probably because it is
already too late for the history?

Would something like   ' noop IS 'history-cold   be possible?

Maybe it would be a good idea to have some kind of -b or --batch command
line argument for non-interactive use, which would turn the boot
message, -status and history off.  (Or maybe a -q or --quiet argument?
Or maybe -q to turn the boot message off and -b to turn history off and
exit on errors?)  In such cases, an error should exit and not be caught
and looped infinitely like seems to happen to me at the moment; unless I
am doing something wrong and should be doing it differently (maybe I
should put catch after serve in 'quit?).