Closed doctorpangloss closed 3 months ago
History size is only configurable at build time. It's the FEATURE_EDITING_HISTORY
setting.
What is it in upstream busybox
? does upstream not respect HISTSIZE
and HISTFILESIZE
? alternatively, could you consider increasing the history in your next build to something much larger or making the size unlimited?
Upstream and busybox-w32 have exactly the same support for history:
HISTSIZE
is ignored.HISTFILESIZE
and HISTFILE
are respected. Changing their values doesn't affect the current shell, only its children. They can be set on startup, though, by putting appropriate commands in ~/.profile
, for example.HISTFILE
is set to an empty string, history will only be retained in memory and not written to a file. Any existing history file will be retained.HISTFILESIZE
can be set to a lower value than the hardcoded default.I've increased the default history size to 1023 in the default configurations for busybox-w32. There are new prerelease binaries (PRE-5333 and above) with this change.
Anyone who prefers a smaller history size can set HISTFILESIZE
.
Support for increasing the history size at runtime would require changes upstream and to busybox-w32.
A slightly different take: leave the maximum history size at 1023 but set the default to 383.
This gives everyone a modest increase over the previous value of 255 while allowing users who want a larger history to increase it via HISTFILESIZE
.
A new prerelease (PRE-5334) is available with this change.
TBH, I don't think I see the point of b5e4d3569f8ee48164b9845801bbc4eb8f62171d , and I think it's counter-productive.
It's not like 1024 commands will drain anyone's RAM on windows, and it's now impossible to set default history of more than 511.
One has to explicitly set it via ~/.profile
to bigger values, and if for whatever reason it's not a login shell, then one has to also have another instance of busybox for the change to take effect, if I understand correctly.
I don't think it's great.
If you insist on having a default MAX value and a smaller initial value, then the initial value should also be configurable IMO.
@rmyorston Isn't possible to have 2 separate define? MAX_HISTORY and DEFAULT_HISTORY
Maybe even having that upstream would be good.
These changes are only intended to adjust the history size in the release builds for Windows. A proper fix for the deficiencies of history in the shells in BusyBox is a matter for upstream and not something I intend to tackle immediately.
These changes are only intended to adjust the history size in the release builds for Windows
Yes, this is what's this repo is about, right? so we're commenting at the correct place.
Anyway, the fact is now that it's impossible to have a default history for the binary (as build configuration) of more than 511 without setting it in ~/.profile
for a login shell, or adding another instance of busybox-w32 for non-login shell, again, if I undersrtand correctly.
Would you consider reverting b5e4d3569f8ee48164b9845801bbc4eb8f62171d ?
Or at least make that 384 a build option as well, so that one could configure arbitrary default history size for the build?
The default history size is now configurable at build time. Since the changes only affect the build system there are no new prerelease binaries.
Thanks.
What is the correct way to increase the number of entries returned by
history
beyond254
? Nothing I do from the Internet seems to work.