[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bash History Behavior Suggestion
From: |
Martin D Kealey |
Subject: |
Re: Bash History Behavior Suggestion |
Date: |
Wed, 21 Aug 2024 02:35:02 +1000 |
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
worse options.
All that said, I would like *some* additional information recorded in the
history file, especially $PWD (when it changes - interpreting "popd"
requires significant mental effort when reading a history file), and
$BASHPID (to track nested shells). With those I would be happy to have
~/.bash_history.d/$TTY, which would greatly reduce the number of files.
Would that be few enough files to satisfy you?
-Martin
On Wed, 21 Aug 2024, 00:38 , <support@eggplantsd.com> wrote:
> 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+output the file (i.e. not the internal history
> list): `--global` to display everything in `.bash_history`, and
> `--local` to restrict output to entries from the current session.
> Everything else would remain as-is.
>
> So this:
>
> #1724136363
> man bash
>
> Becomes this:
>
> #1724136363 [sess create time] [sess PID] [sess TTY]
> man bash
>
> I think it is important to add the local/global flags because it gives
> us some leeway as to how that comment is structured. If you take the
> line of "that's what grep is for", then we're committed to the v1 format
> forever after.
>
> The problem with the stackoverflow solutions is that they are
> all-or-nothing: either mash the history together across all sessions,
> but get strange behavior on history nav & expansion, or don't mash, be
> cut-off from information in concurrent sessions, and end up with the
> occasional unsaved session. Being able to filter the file directly lets
> us look things up without having to slice-and-splice into the internal
> history.
>
> On 2024-08-20 6:14 am, Martin D Kealey wrote:
> > "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 compromises
> > that
> > in the end almost nobody will be happy with it. So if there's to be an
> > additional option - which I'm not convinced of - I suggest that it
> > simply
> > be to set HISTFILE by default to either
> > $HOME/.bash_history.d/{some-pattern-here} (if the directory exists) or
> > ~/.bash_history (matching the current behaviour when that directory
> > does
> > not exist). I would recommend that the pattern include most or all of
> > $$,
> > $TTY, $LOGNAME, and $((EPOCHSECONDS-SECONDS)).
> >
> > Lastly, an awful lot of "default behaviour" is down to whatever
> > /etc/skel/.bashrc and /etc/bash/bashrc that are shipped with Bash by
> > the
> > various distros. Maybe Bash should start shipping some kind of
> > "standard
> > library" of functions that are *expected* to be included with any
> > distro,
> > but are not actually built into the binary.
> >
> > -Martin
> >
> > PS: complaining about "inelegant" in relation to Bash seems a bit
> > pointless.
> >
> > On Tue, 20 Aug 2024 at 16:48, <support@eggplantsd.com> wrote:
> >
> >> 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
> >> behavior would be good enough.
> >>
> >> JS
> >>
> >> On 2024-08-20 2:17 am, Lawrence Velázquez wrote:
> >> > On Tue, Aug 20, 2024, at 1:42 AM, support@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 (or at least would not appreciate
> >> > it changing out from under them). New shopt settings may be doable.
> >>
> >>
>
- Bash History Behavior Suggestion, support, 2024/08/19
- Re: Bash History Behavior Suggestion, Greg Wooledge, 2024/08/19
- Re: Bash History Behavior Suggestion, Martin D Kealey, 2024/08/20
- Re: Bash History Behavior Suggestion, Martin D Kealey, 2024/08/20
- Message not available
- Re: Bash History Behavior Suggestion, support, 2024/08/20
- Re: Bash History Behavior Suggestion, Lawrence Velázquez, 2024/08/20
- Re: Bash History Behavior Suggestion, support, 2024/08/20
- Re: Bash History Behavior Suggestion, Martin D Kealey, 2024/08/20
- Re: Bash History Behavior Suggestion, support, 2024/08/20
- Re: Bash History Behavior Suggestion,
Martin D Kealey <=
- Re: Bash History Behavior Suggestion, support, 2024/08/20
- Re: Bash History Behavior Suggestion, Chet Ramey, 2024/08/28
- Re: Bash History Behavior Suggestion, Chet Ramey, 2024/08/28