On 8/20/24 2:20 PM, supp...@eggplantsd.com wrote:
The problem with the tagged format is that it's *not* usable by grep
Awk would have no problem with it.
limited to exactly whatever magic is built into the "history" command
That's where the magic should be. If that were the official interf
On 8/20/24 1:42 AM, supp...@eggplantsd.com wrote:
I know it can. The suggestion is that the default behavior needs some work:
The default behavior provides mostly mechanism, not policy. There are ways
to do what you want, but those are not suitable for (or desired by)
everyone. So you can chan
The problem with the tagged format is that it's *not* usable by grep
Awk would have no problem with it.
limited to exactly whatever magic is built into the "history" command
That's where the magic should be. If that were the official interface
to `.bash_history`, then bash has freedom to i
The problem with the tagged format is that it's *not* usable by grep, so
you're limited to exactly whatever magic is built into the "history"
command.
"Yuck" is in the eye of the beholder. I've tried numerous other ways to
segregate sessions, and IMO multiple files was the "least yuck" of many
wor
Bash or no bash, spreading history over dozens of files in
`bash_history.d/` is yuck. We already have a comment with the timestamp
in `.bash_history`. If I were implementing the suggestion, I would add
more information to the comment, then add two new flags to the `history`
command that filter
"Missing/disappearing history" is entirely down to the lack of "writing
history as you go", and yes that would be reasonable to offer as a new
opt-in feature.
As for separation of sessions, I strongly suspect that anything between
*total* separation and *none* will result in so many ugly compromis
I wouldn't consider dozens of stackoverflow/askubuntu/etc complaints of
missing/disappearing history "cherry-picked". There were far more than
I sent.
I understand not wanting to pull the rug out from under people, but the
kludges Kealey posted were inelegant. An opt-in for the suggested
be
On Tue, Aug 20, 2024, at 1:42 AM, supp...@eggplantsd.com wrote:
> The suggestion is that the default behavior needs some work
The default behavior is unlikely to change. For every cherry-picked
example of someone unsatisfied with it (bugs aside), there is likely
someone else who prefers it as is
I know it can. The suggestion is that the default behavior needs some
work:
https://askubuntu.com/questions/67283/is-it-possible-to-make-writing-to-bash-history-immediate
https://askubuntu.com/questions/80371/bash-history-handling-with-multiple-terminals
https://askubuntu.com/questions/885531/h
sorry, I meant HISTTIMEFORMAT rather than HISTTIMEFMT
On Tue, 20 Aug 2024 at 14:58, Martin D Kealey
wrote:
> The following suggestions, or close approximations, can all be implemented
> using the existing facilities.
>
> On Tue, 20 Aug 2024 at 05:52, wrote:
>
>> I would suggest:
>>
>> 1. Append
The following suggestions, or close approximations, can all be implemented
using the existing facilities.
On Tue, 20 Aug 2024 at 05:52, wrote:
> I would suggest:
>
> 1. Append to history file immediately on each command.
>
Easily done by putting `history -a` into `PROMPT_COMMAND`
2. Restrict u
On Mon, Aug 19, 2024 at 15:52:22 -0400, supp...@eggplantsd.com wrote:
> I would suggest:
> 2. Restrict up-arrow completion to the history of present session.
This is going to be an *extremely* unpopular suggestion.
Though, I must wonder: do you literally mean *only* the up-arrow (or
Ctrl-P or ESC
Version: GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu)
OS: Linux 6.1.0-23-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.99-1
(2024-07-15) x86_64 GNU/Linux
Issue: History Behavior
For up-arrow completion, I think restricting to the history of the
current bash session is the correct beha
13 matches
Mail list logo
