From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: brickviking Newsgroups: gmane.emacs.tangents Subject: Re: [OT] Not clobbering bash history Date: Fri, 8 Dec 2023 19:22:17 +1300 Message-ID: References: <87wmufm7r7.fsf@catern.com> <87fs12jkik.fsf@yahoo.com> <87ttphlqlo.fsf@catern.com> <87v89ujwa6.fsf@aarsen.me> <86il5g9qs9.fsf@aarsen.me> <864jgy85g5.fsf@aarsen.me> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5856502471278703741==" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3438"; mail-complaints-to="usenet@ciao.gmane.io" Cc: =?UTF-8?B?QXJzZW4gQXJzZW5vdmnDhOKAoQ==?= , sbaugh@catern.com, luangruo@yahoo.com, rms@gnu.org To: emacs-tangents@gnu.org Original-X-From: emacs-tangents-bounces+get-emacs-tangents=m.gmane-mx.org@gnu.org Fri Dec 08 07:52:51 2023 Return-path: Envelope-to: get-emacs-tangents@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rBUjD-0000eD-EG for get-emacs-tangents@m.gmane-mx.org; Fri, 08 Dec 2023 07:52:51 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rBUis-0003sp-Cl; Fri, 08 Dec 2023 01:52:30 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rBUGK-0007rz-Mn for emacs-tangents@gnu.org; Fri, 08 Dec 2023 01:23:00 -0500 Original-Received: from mail-lj1-x22a.google.com ([2a00:1450:4864:20::22a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rBUGI-0000ep-ID; Fri, 08 Dec 2023 01:23:00 -0500 Original-Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2ca2573d132so20602501fa.0; Thu, 07 Dec 2023 22:22:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702016575; x=1702621375; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Qg+wOmZx+yQSOxzQlvyXGfukjWgVz7hEZsnhkkI680I=; b=HCR2VWOs9mdvOl7hnFRHH+o18WPfhWPlTgx/6mfaQ7FMZ3REOjsxcW9NWNCiPgAWLP 3t4DXQSTWxgIEZcZGb2FCTN2vK1lqj6FSUcLslyhOUfhaw15XxylSdjhADDGhCVbmRG7 WCVcw241gBG+tlCWlfWago4bbjmQWDm3JVvBISAQYeQN4kj/k7NUoPUqWedJJ58OSNmb 4gd+lhhVVaouOKJhvVNDxYLaNPIQhAy5RWlx3m+4679UdzGeYya5OBsf0WboP9ibxgGg FgTkYigVIkDwcsaOUtF472TqNCg5048YVy29yD5nPFz5wopFUzGbm/919XdCkZ3OShz0 LOrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702016575; x=1702621375; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Qg+wOmZx+yQSOxzQlvyXGfukjWgVz7hEZsnhkkI680I=; b=dWE+SIseLcfFY4zFFN2t64u6QwIfrgoNnBsWCTs/zblgLlzoJq61pOW4lxvsm8ocsY c11RPNq/F3FeRj/kjBiaKh90gA9zyzHinoo9v59E2rx3jaGAUBJz7Ve0T69PlJGFcKA5 bQPndlZPb5P7pNU09EtKHzVrF8kzphRepiQMExOFAfXpGxExIEUQgInEuJVJQ4SIemc6 9pPkYQ9f4GMDzB7As8aJEfs67gulyAAe/d2oPwHX2qED6iZNE0SBwPsR4X8dA9Jyg5gk advoINcsX05akqMbZrW3iNZmWFlxP32ibvd4N7AKvaJ2gDEHgfz7Nrk2ZUti5ovT5I9F sgVw== X-Gm-Message-State: AOJu0Yzk7sgsbBxZD8yOMXchrpe1Qgiq9qr6Xv6d5MXtfVPuZn4gt4yg zOCB4vHR60u39M9QZzlInMWLq9QRHjYN5tSc7w0nTTImdd4= X-Google-Smtp-Source: AGHT+IFpfd1zz7QZ+1CIWUnpjdMszqVdBifODunbEUv8rIkVNNqtp6zwTcT/MxVgJk2v297/6blR3Wa4Lzk+8vBCYzU= X-Received: by 2002:a2e:3604:0:b0:2ca:16d2:7c45 with SMTP id d4-20020a2e3604000000b002ca16d27c45mr2079786lja.93.1702016574691; Thu, 07 Dec 2023 22:22:54 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::22a; envelope-from=brickviking@gmail.com; helo=mail-lj1-x22a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Fri, 08 Dec 2023 01:52:28 -0500 X-BeenThere: emacs-tangents@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emacs news and miscellaneous discussions outside the scope of other Emacs mailing lists List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-tangents-bounces+get-emacs-tangents=m.gmane-mx.org@gnu.org Original-Sender: emacs-tangents-bounces+get-emacs-tangents=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.tangents:1141 Archived-At: --===============5856502471278703741== Content-Type: multipart/alternative; boundary="000000000000561eea060bf99df1" --000000000000561eea060bf99df1 Content-Type: text/plain; charset="UTF-8" Please continue to CC: me on this thread, as I'm no longer part of the emacs-devel mailing list for the moment. On Fri, 8 Dec 2023 at 16:54, Richard Stallman wrote: > > > If two different shells will try to write history into one single > file, > > > are they doomed to give bad results, one way or another... > > > Not necessarily. If both shells use a single write() syscall on an > > O_APPEND file, they should work as expected to my awareness. > > We are miscommunicating. The way you expect it to work is, in my > opinion, a bad result -- various histories interspersed. > > It seems to me that the crucial thing is for each Bash process > to have its own separate history. > > Do you think that behavior would be bad? > > In my opinion, if I wanted to search for a command I'd previously run that wasn't in my current bash shell history, how would the respective histories be created? Would it involve .bash_history.${PID}, or would it involve .bash_history.${CURRENT_TIMESTAMP} (whatever form that took), or some other combination? In each case, bash can already look up its own history, but when a new Bash shell is started, just which history file is it going to load if there are multiple bash history files saved to disk? The latest by ${CURRENT_TIMESTAMP}? The highest ${PID}? And where will subsequent history be written to? A new ${PID} file? People who run multiple shells in parallel are probably well aware of this now, and I expect that is why decisions were made way back when, to support one history file. The only real argument is whether that history gets erased when a current bash shell closes out and saves its own history over the top (sort of handled by histappend, but not entirely.) > If a bash process decides to rotate the history file as a result of > > HISTSIZE, and another bash process decides to do the same, one of their > > new history entries would be lost due to the other one overriding it. > > This would be a bug. > > Only if they share one single history file. If each has its own > history file, each can handle it as if it were your only Bash process. > > I must admit to having thought that histories could be stored in a sqlite3 database, that way rotation of expired entries (date or number of lines) could be handled by the database itself. However, this means yet another dependency added to the chain where you might not have wished one. And in addition, the licence that sqlite3 is provided under is not a GNU licence, it's one of those licences that pretty much says "We donate this to the public at large" (my summary, not theirs). Another disadvantage for sqlite as a dependency, is that it's not the simplest solution feasible. It is darn quick though, and its development is certainly current and ongoing. One advantage to making the history as a single file (flat or database) is to make searching easier, but that's also its Achilles heel when you want to rotate the file if you're running multiple bash shells. Regards, brickviking --000000000000561eea060bf99df1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Please continue to C= C: me on this thread, as I'm no longer part of the emacs-devel
mail= ing list for the moment.

On Fri, 8= Dec 2023 at 16:54, Richard Stallman <rms@gnu.org> wrote:
=C2=A0 > > If two different shells will try= to write history into one single file,
=C2=A0 > > are they doomed to give bad results, one way or another...=

=C2=A0 > Not necessarily.=C2=A0 If both shells use a single write() sysc= all on an
=C2=A0 > O_APPEND file, they should work as expected to my awareness.
We are miscommunicating.=C2=A0 The way you expect it to work is, in my
opinion, a bad result -- various histories interspersed.

It seems to me that the crucial thing is for each Bash process
to have its own separate history.

Do you think that behavior would be bad?


In my opinion, if I wanted to search f= or a command I'd previously run that=C2=A0
wasn't in my c= urrent=C2=A0bash shell history, how would the respective histories be creat= ed?
Would it involve .bash_history.${PID},=C2=A0 or would it invo= lve=C2=A0
.bash_history.${CURRENT_TIMESTAMP} (whatever form that = took),
or some other combination?

In each case, bas= h can already look up its own history, but when a new Bash shell is
started, just which history file is it going to load if there are multip= le bash history files
saved to disk? The latest by ${CURRENT_TIME= STAMP}? The highest ${PID}?
And where will subsequent history be = written to? A new ${PID} file?

People who run mult= iple shells in parallel are probably well aware of this now, and I expect t= hat is why decisions were made way back when, to support one history file. = The only real argument is whether that history gets erased when a current b= ash shell closes out and saves its own history over the top (sort of handle= d by histappend, but not entirely.)

=C2=A0 > If a bash process decides to rotate the history file as a resul= t of
=C2=A0 > HISTSIZE, and another bash process decides to do the same, one = of their
=C2=A0 > new history entries would be lost due to the other one overridi= ng it.
=C2=A0 > This would be a bug.

Only if they share one single history file.=C2=A0 If each has its own
history file, each can handle it as if it were your only Bash process.
<= br>

I must admit to having thought that his= tories could be stored in a sqlite3 database,
that way rotation o= f expired entries (date or number of lines) could be handled by the
database itself. However, this means yet another dependency added to the= chain
where you might not have wished one. And in addition, the = licence that sqlite3 is provided
under is not a GNU licence, it&#= 39;s one of those licences that pretty much says
"We donate = this to the public at large" (my summary, not theirs).

<= /div>
Another disadvantage for sqlite as a dependency, is that it's= not the simplest solution
feasible. It is darn quick though, and= its development is certainly current and ongoing.
One advantage = to making the history as a single file (flat or database) is to make
<= div>searching easier, but that's also its Achilles heel when you want t= o rotate the file if you're running
multiple bash shells.
=

Regards, brickviking

--000000000000561eea060bf99df1-- --===============5856502471278703741== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline LS0tCnZpYSBlbWFjcy10YW5nZW50cyBtYWlsaW5nIGxpc3QgKGh0dHBzOi8vbGlzdHMuZ251Lm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2VtYWNzLXRhbmdlbnRzKQo= --===============5856502471278703741==--