Re: [RFC PATCH 3/3] FAQ: sync newuser-install

["Daniel Shahaf" <d.s@xxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote on Sat, 27 Aug 2022 15:55 +00:00:
> On Sat, Aug 27, 2022 at 8:41 AM Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
>>
>> From a more theoretical perspective, removing the need to set HISTFILE
>> would allow us to one day move the history storage to something other
>> than files
>
> Given the (ahem) brisk adoption of alternatives to GDBM for ztie, that
> seems unlikely, but if it were going to be implemented wouldn't it
> more likely be as an extension to one of the existing history
> parameters?

Which parameter?  I think such an extension might work as magic syntax
in HISTFILE itself (e.g., using URL syntax, or special-casing arguments
whose first character is "@").  None of the other history parameters seem
particularly suitable to the task?

>> Bart Schaefer wrote on Sat, 27 Aug 2022 02:24 +00:00:
>> >
>> > I haven't worked through all the details yet, but perhaps a zmodload
>> > module?
>>
>> If it's just this, then, s/zmodload module/$fpath function/, surely
>
> A shell function can't be static-linked to the base shell to guarantee
> it's availability.

A module can be left out of the compile; a shell function can be left
out of the $DESTDIR by 'make install'.  A module can be linked
statically; a function can be defined in /etc/zshenv.  Seems like six of
one, half a dozen of the other to me?  It all boils down to "configure and
make correctly", but one of the approaches is a lot easier for users to
edit to taste.

That's assuming what the module/function does is just set the three
parameters.  I'll be quiet for a bit so people have a chance to weigh in
on the idea of enabling history by assigning to a special parameter or
calling a builtin.

Cheers,

Daniel