9:48 a.m.
Hi,
For a long time I've noticed lost history from multiple Terminal tab/windows. It seems
like the last tab or window to close is the history that gets written to .bash_history,
and everything else is just lost.
Somehow I found this:
https://web.archive.org/web/20090815205011/http://www.cuberick.com/2008/1...
I've implemented the suggested two line change to .bash_profile:
# User specific environment and startup programs
shopt -s histappend
PROMPT_COMMAND="history -a;$PROMPT_COMMAND"
The resulting behavior appears to be shells still have their own unique histories while
active. But once closed, their histories become merged (interlaced based on the time they
were issued?) and available when a new shell is created.
I think this would be a pretty cool yet subtle Fedora 39 feature. However,
a) I'm uncertain exactly where this belongs as a default, .bashrc or .bash_profile or
some parent file that's copied to create these files (for new users);
b) if this is (still) an optimal way to go about it;
c) what are the possible negative side effects?
Any thoughts?
--
Chris Murphy
11:02 a.m.
On Tue, 11 Apr 2023 10:48:11 -0400
"Chris Murphy" <lists(a)colorremedies.com> wrote:
Hi,
For a long time I've noticed lost history from multiple Terminal
tab/windows. It seems like the last tab or window to close is the
history that gets written to .bash_history, and everything else is
just lost.
Somehow I found this:
https://web.archive.org/web/20090815205011/http://www.cuberick.com/2008/1...
I've implemented the suggested two line change to .bash_profile:
# User specific environment and startup programs
shopt -s histappend
PROMPT_COMMAND="history -a;$PROMPT_COMMAND"
The resulting behavior appears to be shells still have their own
unique histories while active. But once closed, their histories
become merged (interlaced based on the time they were issued?) and
available when a new shell is created.
I think this would be a pretty cool yet subtle Fedora 39 feature.
However,
a) I'm uncertain exactly where this belongs as a default, .bashrc or
.bash_profile or some parent file that's copied to create these files
(for new users);
I like option 3 if it is going to be automatic.
b) if this is (still) an optimal way to go about it;
Providing it without effort or awareness for users seems like the way
to go.
c) what are the possible negative side effects?
I can't think of any. What good is a history that doesn't include all
the commands that have been used? Well, complex commands. I've turned
off some common commands, like ls, because all they are is clutter. I
also turned off saving duplicate commands, though that only works if
they are contiguous in history. I think that would be a downside to
this if people weren't used to all the clutter in their history.
Though, with Ctrl-R, it really doesn't matter.
I actually wrote a little python program to load history, and eliminate
all duplicate commands in history while preserving order of the
commands. So, the last duplicate command is always the one saved.
Any thoughts?
I have the following defined in .bashrc:
# this logs the history explicitly before exiting a shell
hx ()
{
history -a;
exit;
}
It means that I have to exit using the command hx when closing a
terminal. Not as elegant as an automatic process you are suggesting,
but it seems to work. I'll have to try the process you are
suggesting, (from the link you gave), to see if it results in the
same effect.
12:15 p.m.
On Tue, Apr 11, 2023, at 12:02 PM, stan via devel wrote:
On Tue, 11 Apr 2023 10:48:11 -0400
"Chris Murphy" <lists(a)colorremedies.com> wrote:
> Hi,
>
> For a long time I've noticed lost history from multiple Terminal
> tab/windows. It seems like the last tab or window to close is the
> history that gets written to .bash_history, and everything else is
> just lost.
>
> Somehow I found this:
>
https://web.archive.org/web/20090815205011/http://www.cuberick.com/2008/1...
>
> I've implemented the suggested two line change to .bash_profile:
>
> # User specific environment and startup programs
> shopt -s histappend
> PROMPT_COMMAND="history -a;$PROMPT_COMMAND"
>
> The resulting behavior appears to be shells still have their own
> unique histories while active. But once closed, their histories
> become merged (interlaced based on the time they were issued?) and
> available when a new shell is created.
>
> I think this would be a pretty cool yet subtle Fedora 39 feature.
> However,
>
> a) I'm uncertain exactly where this belongs as a default, .bashrc or
> .bash_profile or some parent file that's copied to create these files
> (for new users);
I like option 3 if it is going to be automatic.
Right.
Which raises the question whether existing user profiles should be modified. There's
pros and cons either way.
And whether that more strongly favors adding this to .bashrc or .bash_profile, and whether
there are subtleties in the resulting behavior depending on which file is used; or if
they're equivalent.
Normally I'd said don't apply a change to existing users. But in this case, I
think the risk of modifying existing user behavior is low, meanwhile the potential for
even more confusion is high if we don't change it.
--
Chris Murphy
12:18 p.m.
On Tue, 2023-04-11 at 13:15 -0400, Chris Murphy wrote:
On Tue, Apr 11, 2023, at 12:02 PM, stan via devel wrote:
> On Tue, 11 Apr 2023 10:48:11 -0400
> "Chris Murphy" <lists(a)colorremedies.com> wrote:
>
> > Hi,
> >
> > For a long time I've noticed lost history from multiple Terminal
> > tab/windows. It seems like the last tab or window to close is the
> > history that gets written to .bash_history, and everything else is
> > just lost.
> >
> > Somehow I found this:
> >
https://web.archive.org/web/20090815205011/http://www.cuberick.com/2008/1...
> >
> > I've implemented the suggested two line change to .bash_profile:
> >
> > # User specific environment and startup programs
> > shopt -s histappend
> > PROMPT_COMMAND="history -a;$PROMPT_COMMAND"
> >
> > The resulting behavior appears to be shells still have their own
> > unique histories while active. But once closed, their histories
> > become merged (interlaced based on the time they were issued?) and
> > available when a new shell is created.
> >
> > I think this would be a pretty cool yet subtle Fedora 39 feature.
> > However,
> >
> > a) I'm uncertain exactly where this belongs as a default, .bashrc or
> > .bash_profile or some parent file that's copied to create these files
> > (for new users);
>
> I like option 3 if it is going to be automatic.
Right.
Which raises the question whether existing user profiles should be modified. There's
pros and cons either way.
And whether that more strongly favors adding this to .bashrc or .bash_profile, and
whether there are subtleties in the resulting behavior depending on which file is used; or
if they're equivalent.
Normally I'd said don't apply a change to existing users. But in this case, I
think the risk of modifying existing user behavior is low, meanwhile the potential for
even more confusion is high if we don't change it.
It is a pretty strong principle in Fedora that we do *not* mess with
users' home directories and configuration after creation. (Software
packaged in Fedora might of course mess with its own configuration, but
Fedora itself should not go around poking stuff like this).
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
3:39 a.m.
Dne 11. 04. 23 v 18:02 stan via devel napsal(a):
I have the following defined in .bashrc:
# this logs the history explicitly before exiting a shell
hx ()
{
history -a;
exit;
}
It means that I have to exit using the command hx when closing a
terminal.
What about using `~/.bash_logout` to avoid the need of `hx`?
Vít
10:40 a.m.
On Wed, 12 Apr 2023 10:39:44 +0200
Vít Ondruch <vondruch(a)redhat.com> wrote:
Dne 11. 04. 23 v 18:02 stan via devel napsal(a):
>
> I have the following defined in .bashrc:
>
> # this logs the history explicitly before exiting a shell
> hx ()
> {
> history -a;
> exit;
> }
>
> It means that I have to exit using the command hx when closing a
> terminal.
What about using `~/.bash_logout` to avoid the need of `hx`?
I had to do some research to even understand what you were asking.
With that caveat, it seems that a .bash_logout only executes on login
shells. So, it would not save the history of terminals in X when they
were closed. Am I misunderstanding?
I did find something that might work in that case, at this link.
https://superuser.com/questions/410525/explain-why-bash-logout-wont-run-c...
"""
~/.bash_logout is only run if it you explicitly exit the shell with
exit or logout, or by typing Control-D to enter an end-of-file at the
command prompt. If you close the terminal emulator, processes are sent
SIGHUP, and bash doesn’t run ~/.bash_logout in that case.
If you want to perform work any time bash exits (and whether it’s a
login shell or not), use trap foo EXIT. The most convenient way to do
this is to put your code in a shell function, e.g.,:
print_goodbye () { echo Goodbye; }
trap print_goodbye EXIT
"""
Typing exit or logout is more keystrokes than hx, so .bash_logout is not
really compelling. The trap looks promising, I assume that I would put
save_history_on_exit () {history -a;}
trap save_history_on_exit EXIT
in .bashrc. Basically, running a .bash_logout in a different way.
Thanks.
5:48 a.m.
Dne 12. 04. 23 v 17:40 stan via devel napsal(a):
On Wed, 12 Apr 2023 10:39:44 +0200
Vít Ondruch <vondruch(a)redhat.com> wrote:
> Dne 11. 04. 23 v 18:02 stan via devel napsal(a):
>> I have the following defined in .bashrc:
>>
>> # this logs the history explicitly before exiting a shell
>> hx ()
>> {
>> history -a;
>> exit;
>> }
>>
>> It means that I have to exit using the command hx when closing a
>> terminal.
>
> What about using `~/.bash_logout` to avoid the need of `hx`?
I had to do some research to even understand what you were asking.
Sorry, I am not expert in this field. The discussion just caught my
attention and that was result of my very brief research.
With that caveat, it seems that a .bash_logout only executes on
login
shells. So, it would not save the history of terminals in X when they
were closed. Am I misunderstanding?
I did find something that might work in that case, at this link.
https://superuser.com/questions/410525/explain-why-bash-logout-wont-run-c...
"""
~/.bash_logout is only run if it you explicitly exit the shell with
exit or logout, or by typing Control-D to enter an end-of-file at the
command prompt. If you close the terminal emulator, processes are sent
SIGHUP, and bash doesn’t run ~/.bash_logout in that case.
If you want to perform work any time bash exits (and whether it’s a
login shell or not), use trap foo EXIT. The most convenient way to do
this is to put your code in a shell function, e.g.,:
print_goodbye () { echo Goodbye; }
trap print_goodbye EXIT
"""
Interesting. Thx for the link.
Typing exit or logout is more keystrokes than hx, so .bash_logout is not
really compelling.
Ctrl+D is what I am using all the time. That is probably less keystrokes
then `hx`, because you save the pressing the Enter ;)
Vít
The trap looks promising, I assume that I would put
save_history_on_exit () {history -a;}
trap save_history_on_exit EXIT
in .bashrc. Basically, running a .bash_logout in a different way.
Thanks.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
10:25 a.m.
On Thu, 13 Apr 2023 12:48:01 +0200
Vít Ondruch <vondruch(a)redhat.com> wrote:
Dne 12. 04. 23 v 17:40 stan via devel napsal(a):
> On Wed, 12 Apr 2023 10:39:44 +0200
> Vít Ondruch <vondruch(a)redhat.com> wrote:
>
>> What about using `~/.bash_logout` to avoid the need of `hx`?
> I had to do some research to even understand what you were asking.
Sorry, I am not expert in this field. The discussion just caught my
attention and that was result of my very brief research.
What I meant is that I wasn't aware of .bash_logout until you asked
about it. So I learned by researching it, and improved what I was
doing.
> Typing exit or logout is more keystrokes than hx, so
.bash_logout
> is not really compelling.
Ctrl+D is what I am using all the time. That is probably less
keystrokes then `hx`, because you save the pressing the Enter ;)
You're right. And it flows off the fingers nicely. I ended up adding
the trap command to my .bashrc, so now it doesn't matter how I close
the session, it will always be appended to history. I currently have
the PROMPT_COMMAND altered to add history -a too, so I have belt and
suspenders. I haven't really noticed any issues with the appends to
.bash_history every time a new prompt happens, so might leave it. On
the other hand, it isn't really necessary anymore.
10:13 a.m.
On 12 Apr 2023, at 16:40, stan via devel
<devel(a)lists.fedoraproject.org> wrote:
On Wed, 12 Apr 2023 10:39:44 +0200
Vít Ondruch <vondruch(a)redhat.com> wrote:
> Dne 11. 04. 23 v 18:02 stan via devel napsal(a):
>>
>> I have the following defined in .bashrc:
>>
>> # this logs the history explicitly before exiting a shell
>> hx ()
>> {
>> history -a;
>> exit;
>> }
>>
>> It means that I have to exit using the command hx when closing a
>> terminal.
>
>
> What about using `~/.bash_logout` to avoid the need of `hx`?
I had to do some research to even understand what you were asking.
With that caveat, it seems that a .bash_logout only executes on login
shells. So, it would not save the history of terminals in X when they
were closed. Am I misunderstanding?
For lots of reasons it became recommended that all gui terminal sessions should be login
sessions. One reason being that .bash_profile may not be run in a sub process.
Barry
I did find something that might work in that case, at this link.
https://superuser.com/questions/410525/explain-why-bash-logout-wont-run-c...
"""
~/.bash_logout is only run if it you explicitly exit the shell with
exit or logout, or by typing Control-D to enter an end-of-file at the
command prompt. If you close the terminal emulator, processes are sent
SIGHUP, and bash doesn’t run ~/.bash_logout in that case.
If you want to perform work any time bash exits (and whether it’s a
login shell or not), use trap foo EXIT. The most convenient way to do
this is to put your code in a shell function, e.g.,:
print_goodbye () { echo Goodbye; }
trap print_goodbye EXIT
"""
Typing exit or logout is more keystrokes than hx, so .bash_logout is not
really compelling. The trap looks promising, I assume that I would put
save_history_on_exit () {history -a;}
trap save_history_on_exit EXIT
in .bashrc. Basically, running a .bash_logout in a different way.
Thanks.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
10:14 a.m.
On 13 Apr 2023, at 16:13, Barry <barry(a)barrys-emacs.org>
wrote:
>> On 12 Apr 2023, at 16:40, stan via devel <devel(a)lists.fedoraproject.org>
wrote:
>>
>> On Wed, 12 Apr 2023 10:39:44 +0200
>> Vít Ondruch <vondruch(a)redhat.com> wrote:
>>
>> Dne 11. 04. 23 v 18:02 stan via devel napsal(a):
>>>
>>> I have the following defined in .bashrc:
>>>
>>> # this logs the history explicitly before exiting a shell
>>> hx ()
>>> {
>>> history -a;
>>> exit;
>>> }
>>>
>>> It means that I have to exit using the command hx when closing a
>>> terminal.
>>
>>
>> What about using `~/.bash_logout` to avoid the need of `hx`?
>
> I had to do some research to even understand what you were asking.
> With that caveat, it seems that a .bash_logout only executes on login
> shells. So, it would not save the history of terminals in X when they
> were closed. Am I misunderstanding?
For lots of reasons it became recommended that all gui terminal sessions should be login
sessions. One reason being that .bash_profile may not be run in a sub process.
/sub/parent/
Barry
>
> I did find something that might work in that case, at this link.
>
>
https://superuser.com/questions/410525/explain-why-bash-logout-wont-run-c...
>
> """
> ~/.bash_logout is only run if it you explicitly exit the shell with
> exit or logout, or by typing Control-D to enter an end-of-file at the
> command prompt. If you close the terminal emulator, processes are sent
> SIGHUP, and bash doesn’t run ~/.bash_logout in that case.
>
> If you want to perform work any time bash exits (and whether it’s a
> login shell or not), use trap foo EXIT. The most convenient way to do
> this is to put your code in a shell function, e.g.,:
>
> print_goodbye () { echo Goodbye; }
> trap print_goodbye EXIT
> """
>
> Typing exit or logout is more keystrokes than hx, so .bash_logout is not
> really compelling. The trap looks promising, I assume that I would put
> save_history_on_exit () {history -a;}
> trap save_history_on_exit EXIT
> in .bashrc. Basically, running a .bash_logout in a different way.
>
> Thanks.
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
11:07 a.m.
On Tue, 2023-04-11 at 10:48 -0400, Chris Murphy wrote:
Hi,
For a long time I've noticed lost history from multiple Terminal tab/windows. It
seems like the last tab or window to close is the history that gets written to
.bash_history, and everything else is just lost.
Somehow I found this:
https://web.archive.org/web/20090815205011/http://www.cuberick.com/2008/1...
I've implemented the suggested two line change to .bash_profile:
# User specific environment and startup programs
shopt -s histappend
PROMPT_COMMAND="history -a;$PROMPT_COMMAND"
The resulting behavior appears to be shells still have their own unique histories while
active. But once closed, their histories become merged (interlaced based on the time they
were issued?) and available when a new shell is created.
I think this would be a pretty cool yet subtle Fedora 39 feature. However,
a) I'm uncertain exactly where this belongs as a default, .bashrc or .bash_profile or
some parent file that's copied to create these files (for new users);
b) if this is (still) an optimal way to go about it;
c) what are the possible negative side effects?
Any thoughts?
I've been doing something like this for years, but I wouldn't
necessarily recommend it as an OOTB default. It has some interesting
subtleties, like the order of the command history you get when you hit
'up' changes depending on when the history is updated by other
terminals and when the terminal you're in reloads it.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
12:06 p.m.
On Tue, Apr 11, 2023, at 12:07 PM, Adam Williamson wrote:
I've been doing something like this for years, but I
wouldn't
necessarily recommend it as an OOTB default. It has some interesting
subtleties, like the order of the command history you get when you hit
'up' changes depending on when the history is updated by other
terminals and when the terminal you're in reloads it.
I'm not seeing this effect. While active, the shells apparently have completely unique
histories, and don't interact with each other (until they're closed). From time to
time I see zero length files, e.g. .bash_history-04863.tmp appear but I don't know
what they do, there's nothing in them.
--
Chris Murphy
12:20 p.m.
On Tue, 2023-04-11 at 13:06 -0400, Chris Murphy wrote:
On Tue, Apr 11, 2023, at 12:07 PM, Adam Williamson wrote:
> I've been doing something like this for years, but I wouldn't
> necessarily recommend it as an OOTB default. It has some interesting
> subtleties, like the order of the command history you get when you hit
> 'up' changes depending on when the history is updated by other
> terminals and when the terminal you're in reloads it.
I'm not seeing this effect. While active, the shells apparently have completely
unique histories, and don't interact with each other (until they're closed). From
time to time I see zero length files, e.g. .bash_history-04863.tmp appear but I don't
know what they do, there's nothing in them.
The version I use is a file in /etc/profile.d that does this:
HISTSIZE=1048576
HISTFILESIZE=1048576
LAST_HISTORY_WRITE=$SECONDS
function prompt_command {
if [ $(($SECONDS - $LAST_HISTORY_WRITE)) -gt 60 ]; then
history -a && history -c && history -r
LAST_HISTORY_WRITE=$SECONDS
fi
}
PROMPT_COMMAND="${PROMPT_COMMAND:-:} ; prompt_command"
so I guess that's the difference; mine clears and reloads the history
(if it's been more than 60 seconds since the last time it did it).
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
3:41 p.m.
On 4/11/23 19:20, Adam Williamson wrote:
The version I use is a file in /etc/profile.d that does this:
HISTSIZE=1048576
HISTFILESIZE=1048576
LAST_HISTORY_WRITE=$SECONDS
function prompt_command {
if [ $(($SECONDS - $LAST_HISTORY_WRITE)) -gt 60 ]; then
history -a && history -c && history -r
LAST_HISTORY_WRITE=$SECONDS
fi
}
PROMPT_COMMAND="${PROMPT_COMMAND:-:} ; prompt_command"
so I guess that's the difference; mine clears and reloads the history
(if it's been more than 60 seconds since the last time it did it).
Very similar to what I've been using for years, in /etc/profile.d
HISTSIZE=190000
PROMPT_COMMAND='if [ $SECONDS -gt $[${lastsavedhistory-0}+10] ]; then history -a;
lastsavedhistory="$SECONDS"; fi; '"$PROMPT_COMMAND"
Regards.
--
Roberto Ragusa mail at robertoragusa.it
12:18 p.m.
Once upon a time, Chris Murphy <lists(a)colorremedies.com> said:
I've implemented the suggested two line change to .bash_profile:
# User specific environment and startup programs
shopt -s histappend
This is already in the default /etc/bashrc, at least on Fedora 37 on
CentOS 7 (systems at hand I checked).
PROMPT_COMMAND="history -a;$PROMPT_COMMAND"
I wouldn't do that part; that's additional disk I/O for every prompt.
Especially when the system might be having issues, users (especially
root) don't need something interfering with every command. This would
mean an NFS home would insta-hang at the slightest issue.
--
Chris Adams <linux(a)cmadams.net>
6:52 p.m.
On Tue, Apr 11 2023 at 12:18:58 PM -0500, Chris Adams
<linux(a)cmadams.net> wrote:
I wouldn't do that part; that's additional disk I/O for every
prompt.
Especially when the system might be having issues, users (especially
root) don't need something interfering with every command. This would
mean an NFS home would insta-hang at the slightest issue.
Hm, but consider also that if the filesystem is slow or unreliable,
then your entire desktop is going to hang as well. (It probably
_shouldn't_ hang, but it absolutely does.) You cannot even open
gnome-terminal until the I/O operations complete. With that baseline in
mind, I'd say the benefits outweigh the costs, but we should make it
easy to opt out somehow.
Michael
6:57 p.m.
Once upon a time, Michael Catanzaro <mcatanzaro(a)redhat.com> said:
On Tue, Apr 11 2023 at 12:18:58 PM -0500, Chris Adams
<linux(a)cmadams.net> wrote:
>I wouldn't do that part; that's additional disk I/O for every prompt.
>Especially when the system might be having issues, users (especially
>root) don't need something interfering with every command. This would
>mean an NFS home would insta-hang at the slightest issue.
Hm, but consider also that if the filesystem is slow or unreliable,
then your entire desktop is going to hang as well. (It probably
_shouldn't_ hang, but it absolutely does.) You cannot even open
gnome-terminal until the I/O operations complete. With that baseline
in mind, I'd say the benefits outweigh the costs, but we should make
it easy to opt out somehow.
You are assuming Fedora is only used for desktops.
--
Chris Adams <linux(a)cmadams.net>
7:38 p.m.
Chris Adams wrote:
Once upon a time, Michael Catanzaro <mcatanzaro(a)redhat.com>
said:
> On Tue, Apr 11 2023 at 12:18:58 PM -0500, Chris Adams
> <linux(a)cmadams.net> wrote:
>>I wouldn't do that part; that's additional disk I/O for every prompt.
>>Especially when the system might be having issues, users (especially
>>root) don't need something interfering with every command. This would
>>mean an NFS home would insta-hang at the slightest issue.
>
> Hm, but consider also that if the filesystem is slow or unreliable,
> then your entire desktop is going to hang as well. (It probably
> _shouldn't_ hang, but it absolutely does.) You cannot even open
> gnome-terminal until the I/O operations complete. With that baseline
> in mind, I'd say the benefits outweigh the costs, but we should make
> it easy to opt out somehow.
You are assuming Fedora is only used for desktops.
Indeed. I think that setting PROMPT_COMMAND as an array in
the default configuration would be the place to start. Then
packages which enable such functionality can be added with
more granularity.
If the desktop working group wants to default to having such
a configuration enabled, it can be done without affecting
the server images, etc. And folks can easily opt-out even
on the desktop. (I'd still prefer if it was opt-in for the
desktop, but that's just an opinion.)
That makes it easier to add snippets to /etc/profile.d
rather than coordinating everything via the setup package.
Hard-coding a default for everyone which leaves a good
number of folks unhappy in either case is not ideal.
--
Todd
10:53 a.m.
On Tue, Apr 11 2023 at 08:38:39 PM -0400, Todd Zullinger
<tmz(a)pobox.com> wrote:
Indeed. I think that setting PROMPT_COMMAND as an array in
the default configuration would be the place to start. Then
packages which enable such functionality can be added with
more granularity.
If the desktop working group wants to default to having such
a configuration enabled, it can be done without affecting
the server images, etc. And folks can easily opt-out even
on the desktop. (I'd still prefer if it was opt-in for the
desktop, but that's just an opinion.)
That makes it easier to add snippets to /etc/profile.d
rather than coordinating everything via the setup package.
Hard-coding a default for everyone which leaves a good
number of folks unhappy in either case is not ideal.
Can anybody think of disadvantages to this approach? Sounds like a good
option?
11:14 a.m.
On Tue, 2023-04-11 at 12:18 -0500, Chris Adams wrote:
Once upon a time, Chris Murphy <lists(a)colorremedies.com> said:
> I've implemented the suggested two line change to .bash_profile:
>
> # User specific environment and startup programs
> shopt -s histappend
This is already in the default /etc/bashrc, at least on Fedora 37 on
CentOS 7 (systems at hand I checked).
yes and Centos 7 means all Fedora since a long time ...
I set HISTSIZE=400000 in /etc/profile directly , this because if
profile runs and set HISTSIZE to 1000 sometimes happens that
.bash_history is truncated .
I also do backups of my $HOME/.bash_history
(I started with 100000 I doubled 200000 , and my history now have more
than 200000 entries )
> PROMPT_COMMAND="history -a;$PROMPT_COMMAND"
I wouldn't do that part; that's additional disk I/O for every
prompt.
Especially when the system might be having issues, users (especially
root) don't need something interfering with every command. This
would
mean an NFS home would insta-hang at the slightest issue.
--
Chris Adams <linux(a)cmadams.net>
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
Sérgio M. B.
11:54 a.m.
Once upon a time, Sérgio Basto <sergio(a)serjux.com> said:
On Tue, 2023-04-11 at 12:18 -0500, Chris Adams wrote:
> This is already in the default /etc/bashrc, at least on Fedora 37 on
> CentOS 7 (systems at hand I checked).
yes and Centos 7 means all Fedora since a long time ...
Specifically, since Fedora 18 development, in 2012.
https://bugzilla.redhat.com/show_bug.cgi?id=815810
Although that had a superfluous "history -a" added as well that was
dropped a year ago:
https://bugzilla.redhat.com/show_bug.cgi?id=1871744
Personally, the only changes I do to bash history settings are
increasing the size (1000 by default, 10000 on a few systems where I
have more-active terminal sessions) and adding timestamps to the history
with:
HISTTIMEFORMAT="%Y-%m-%d %T "
--
Chris Adams <linux(a)cmadams.net>
1:19 p.m.
On Tue, Apr 11, 2023 at 10:48:11AM -0400, Chris Murphy wrote:
Hi,
For a long time I've noticed lost history from multiple Terminal tab/windows. It
seems like the last tab or window to close is the history that gets written to
.bash_history, and everything else is just lost.
Somehow I found this:
https://web.archive.org/web/20090815205011/http://www.cuberick.com/2008/1...
I've implemented the suggested two line change to .bash_profile:
# User specific environment and startup programs
shopt -s histappend
PROMPT_COMMAND="history -a;$PROMPT_COMMAND"
The resulting behavior appears to be shells still have their own
unique histories while active. But once closed, their histories become merged (interlaced
based on the time they were issued?) and available when a new shell is created.
I think this would be a pretty cool yet subtle Fedora 39 feature. However,
I'm glad that you've found something that you like, but please don't
mess with the default. I don't need extra I/O on every command, and
for other reasons prefer the current behaviour.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
2:48 p.m.
Chris Murphy wrote:
I've implemented the suggested two line change to
.bash_profile:
# User specific environment and startup programs
shopt -s histappend
PROMPT_COMMAND="history -a;$PROMPT_COMMAND"
[...]
Any thoughts?
As others have said, enabling this by default has
consequences which would make a good number of folks
unhappy, so it's probably not an ideal candidate to enable
by default.
One thing worth noting, I think, is that since bash-5.1,
PROMPT_COMMAND may be an array. This lends itself to adding
something in /etc/profile.d which appends 'history -a' to
the PROMPT_COMMAND array, e.g.:
PROMPT_COMMAND+=( history -a )
(which would grow half a dozen or so lines with the needed
checking that 'history -a' wasn't already present, that
PROMPT_COMMAND was an array instead of a string, etc.)
I don't believe that Fedora's defaults from the setup
package currently use an array, so perhaps working toward
that change would be a good first step. Once in place, a
package which provides the history appending behavior could
be easily added and those who prefer it could install it.
--
Todd
400
days inactive
402
days old
22 comments
11 participants
participants (11)
-
Adam Williamson -
Barry -
Chris Adams -
Chris Murphy -
Michael Catanzaro -
Richard W.M. Jones -
Roberto Ragusa -
stan -
Sérgio Basto -
Todd Zullinger -
Vít Ondruch