Re: HISTFILE support for /bin/sh

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sat, 06 Jul 2024 13:44:30 -0700
    From:        "Greg A. Woods" <woods%planix.ca@localhost>
    Message-ID:  <m1sQCGk-003UKYC@more.local>

  | I had forgot that /bin/sh "just" uses libedit.

It turns out that libedit needs a minor change to be able to operate
the way sh needs it to work.  That should appear soon, the sh changes
can't happen before that gets done.

  | I think what you've proposed all makes good sense and fits well into a
  | simple and elegant /bin/sh!

This is what currently exists in the updated sh manual page - there are
some other changes incl for "fc -z" and more, but nothing there that's
important.

I wouldn't call this wording either simple or elegant, suggestions
welcome.

     HISTAPPEND
                If set to one of 'true', 'yes', 'on', or an integral value
                greater than zero, and if HISTFILE is also set, and is a valid
                history file, then as commands are read and added to the
                history buffer, they are also written to the HISTFILE named.

     HISTFILE   When assigned to in an interactive shell the contents of the
                file named by expanding the new value of HISTFILE will, if it
                exists, can be opened for reading, and is a suitable sh
                history file (one previously written by sh), be read into the
                history buffer, appending its contents to any existing history
                entries.  If HISTFILE is set when sh exits, after any EXIT
                trap has been evaluated, and if HISTAPPEND is not enabled; or
                if HISTFILE is assigned when HISTAPPEND is enabled; or if
                HISTAPPEND is enabled when HISTFILE is set; the contents of
                the history buffer will be written to the file named after
                expanding this variable.  If the file named did not previously
                exist, it will be created.  If it did exist, it must be
                writable.  The file will be truncated, and then if owned by
                the current user, the current history buffer will be written
                to it.

                When used for reading or writing history entries, variable and
                arithmetic expansions are performed, upon its value to produce
                a file name, and if the HISTFILE variable was set by this
                shell, rather than obtained from the environment, command
                substitutions will also be performed.  No file will be used if
                an expansion error occurs, or if there is a command
                substitution in a value obtained from the encironment.

     HISTSIZE   The number of lines in the history buffer for the shell.  If
                unset, or set to an empty string, 100 lines will be used.
                Attempts to set HISTSIZE to anything other than a string of
                digits will generate an error.  An invalid value found in the
                environment will be ignored.


  | If libedit were fixed to allow HISTSIZE=0 to clear the history buffer
  | (and for the duration disable history),

You really wouldn't want to do that, or line editing really wouldn't
work well (I think - not sure I really understand how libedit works).
We could easily make HISTSIZE=0 clear the history buffer, the same
way that fc -z does, but there would still be 1 entry available in
the history buffer which would hold the most recent command.

There's not any way to actually disable the history buffer in sh
(not now, not after these changes.)

  | Indeed given the current definition of HISTSIZE which you described as
  | being "the number of history entries that are not allowed to exist" then
  | for most purposes setting HISTSIZE=1 as a means to (mostly?) clear the
  | buffer would suffice.

I have changed the code to add 1 to the HISTSIZE value as that is passed
to libedit, so HISTSIZE=100 really means 100 entries in the history
buffer, rather than 99 (and 1 really means 1, 0 does as well, but that's
a special case).

Since I know the text above is hard to read (English, while my native
language, is not the one I prefer to write, I like C, or sh, or tcl,
or ...) if there are any questions about what it means, please ask.
Maybe we can improve it before it gets committed.

kre