Re: history builtin with no HISTFILE

[Chet Ramey]

On 8/2/23 1:23 PM, Grisha Levit wrote:
> On Wed, Aug 2, 2023, 10:45 Chet Ramey <chet.ramey@case.edu> wrote:
> > On 7/27/23 10:16 PM, Grisha Levit wrote:
> > > If the `history' builtin is used with no filename argument and the HISTFILE
> > > variable is unset, the Readline default history file ~/.history is used.
> >
> > It makes sense to use some default filename if the user explicitly asks
> > for the history to be read or written. Better than silently doing nothing
> > or (slightly better) warning if HISTFILE is unset.
> >
> > > Since Bash normally doesn't perform any history file operations if HISTFILE
> > > is empty or unset, I think it would make sense for `history' to do the same.
> >
> > What does `normally' mean here? I can see not reading from the history at
> > startup or not writing to it at shell termination, but in your example the
> > `history' builtin is being used to explicitly save the history somewhere.
>
> The way I encountered this was that I usually run `HISTFILE=' when I
> want to disable saving history for a particular session.  At some
> point I added `history -a' to PROMPT_COMMAND, but this combination
> results in the (accurate) error message:
>
> bash: history: : cannot create: No such file or directory

Not such a great error message, but ok.

> So I thought I would instead do `unset HISTFILE' -- this made the
> error go away and I confirmed ~/.bash_history was not getting updated
> (and neither was any other file!).  At some later point I created
> ~/.history and then later noticed that this file started getting
> written by `history -a'.

Yeah, if the application doesn't set a filename to use for the history,
you get the history library default. It's not unique to bash.

> My mental model was "the history builtin with no filename argument
> operates on whatever history file the shell is set up to write to on
> shutdown" and "explicitly setting to null or unsetting HISTFILE tells
> the shell not to save history anywhere".

Hmmmm. That's fair when you have to actively unset HISTFILE. To be fair,
one of the basic assumptions is that no one would ever direct the shell
to write the history to a file without making sure there's a file to
write to, and not expecting a warning if they tried to.

However:
> I would guess that the majority of `history -[anrw]' invocations are
> `history -a' in PROMPT_COMMAND and the like, and that users unset
> HISTFILE to signal that they don't want history written -- and usually
> this works fine because they don't have a ~/.history to append to.

So this tells me that you want `history' to exit silently and successfully
if a filename is not supplied and HISTFILE is unset or null.


> Sorry for the long message.

Your messages are by no means the longest.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/