Re: [RFC PATCH 0/3] Improve defaults

[Felipe Contreras <felipe.contreras@xxxxxxxxx>]

On Wed, Aug 24, 2022 at 5:18 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> On Wed, Aug 24, 2022 at 2:50 PM Felipe Contreras
> <felipe.contreras@xxxxxxxxx> wrote:
> >
> > On Wed, Aug 24, 2022 at 3:58 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> > >
> > > Side-effects upon existing uses of "fc -p" are not
> > > considered,
> >
> > How are they not considered?
>
> "fc -p" with no other arguments explicitly resets the variables to
> their defaults.

Yes, which includes HISTFILE="", so SAVEHIST doesn't matter.

> The current default for SAVEHIST is zero, so having
> that become nonzero is an issue.

How? Saving 1000 lines to "" is a no-op.

If the user does "fc -p tmp_history" then SAVEHIST will not be the
default, but whatever the user has specified.

> Changing the default HISTSIZE is less of a concern but still affects "fc -p".

Only if the user hasn't set HISTSIZE.

I'm not familiar with "fc -p/P", but I read the code, and I fail to
see the issue.

> > > nor are use cases involving SHARE_HISTORY, APPEND_HISTORY,
> > > INC_APPEND_HISTORY, and HIST_SAVE_NO_DUPS,
> >
> > Once again, how are they not considered?
>
> Simply that usually when any of those are set, which is not uncommon,
> it makes much less sense to have equivalent values of SAVEHIST and
> HISTSIZE.

Yes, but if the user has set APPEND_HISTORY, and SAVEHIST=HISTSIZE
doesn't make much sense, then the user surely has set SAVEHIST to a
value that does make sense (i.e. not 0), therefore changing the
default value of SAVEHIST is irrelevant.

> As I said, that's probably a case where they're all being
> set anyway, but these patches aren't helpful.

The default values don't have to be helpful in all configurations,
only in the majority of them. For all the rest the user can specify
something other than the default, like they are doing right now.

-- 
Felipe Contreras