From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Arsen =?utf-8?Q?Arsenovi=C4=87?= Newsgroups: gmane.emacs.devel Subject: Re: [OT] Not clobbering bash history Date: Sun, 26 Nov 2023 11:20:03 +0100 Message-ID: <86il5g9qs9.fsf@aarsen.me> References: <87wmufm7r7.fsf@catern.com> <87fs12jkik.fsf@yahoo.com> <87ttphlqlo.fsf@catern.com> <87v89ujwa6.fsf@aarsen.me> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19360"; mail-complaints-to="usenet@ciao.gmane.io" Cc: brickviking@gmail.com, sbaugh@catern.com, luangruo@yahoo.com, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 02 23:36:14 2023 Return-path: Envelope-to: ged-emacs-devel@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 1r9Yas-0004q0-FR for ged-emacs-devel@m.gmane-mx.org; Sat, 02 Dec 2023 23:36:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r9YaE-0006yt-7I; Sat, 02 Dec 2023 17:35:34 -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 1r9YaA-0006ye-RN for emacs-devel@gnu.org; Sat, 02 Dec 2023 17:35:30 -0500 Original-Received: from mout-p-202.mailbox.org ([2001:67c:2050:0:465::202]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1r9Ya9-0000Bq-7m; Sat, 02 Dec 2023 17:35:30 -0500 Original-Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:b231:465::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4SjPrn1QxYz9sb2; Sat, 2 Dec 2023 23:35:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aarsen.me; s=MBO0001; t=1701556521; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zBs6xvDmQKL174LeO0FlP+CHvH9hUq/QSsCRyY1H/jQ=; b=lcV+5INWbZSSFAbvNwyp7/aRpEjVtwduet5Fumg/JAdpWgkAA36cQlkkO3PUKDpzpBr3XH tS6+OQezUjoE8oGtQKbnDHI8wbxOocr9V1PDN1vX7Ofd1RKRpbRBsXkiSpuIKUh0v5FDe4 D6EdoAX1iUrSuvKj7Dg1sFbCd794W+c5Nry7aCfnduXBHFrDdQrvfv5Ma5voYLC8HSBiWF zUhvnAfmIIBfPE3GSamFduFOiPlDWn9s+yjvgOl7EYGNy5nBt7m42+om4z49Iwx3AHsz/1 u2LVWR0JU6wOgWaWOJ2Eu7x6y0FYXnQ/qD+PAtZodcKxv4dBH0hadrNvIwYoUQ== In-reply-to: X-TUID: e7aqPNPQo5EJ X-Rspamd-Queue-Id: 4SjPrn1QxYz9sb2 Received-SPF: pass client-ip=2001:67c:2050:0:465::202; envelope-from=arsen@aarsen.me; helo=mout-p-202.mailbox.org X-Spam_score_int: 6 X-Spam_score: 0.6 X-Spam_bar: / X-Spam_report: (0.6 / 5.0 requ) BAYES_00=-1.9, DATE_IN_PAST_96_XX=3.405, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:313478 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Richard Stallman writes: > > > Should we suggest that the Bash developer add a feature to handle t= his > > > case (multiple shells in parallel) the "right" way? If many users > > > would like it, that could make it worth building in. > > > That would be very nice. This issue has almost been prolific enough = to > > force me to switch shells. > > How about if you (or someone) write a description of the behavior you > would like Bash to offer (at least as an option)? Sure. libhistory should, on recall attempt, try to re-read the history file from the last point it was on in order to catch new histories, it should append to the file, and it should attempt to lock the file via flock or similar if such facilities are available (just in case). Bash already implements this partially, lacking the update-on-recall functionality (I believe ZSH calls its version of this "share_history"), and lacking a way to append a history command *before* it is executed, to my awareness. In the event of truncation, libhistory needs to be careful not to lose any histories that were to be submitted in between the moment of determination of truncation and commitment of the truncation to disk. On occasion, I wish histories were stored in a SQLite3 database :-) As a QoL feature, bash should prevent history truncation if ran with =2D-norc or other flags that would inhibit HISTFILE being set potentially. I suspect that this latter change alone would prevent the issue I was seeing (but I can't be sure, since I never caught bash in the act of history file truncation). Thanks, have a lovely day. =2D-=20 Arsen Arsenovi=C4=87 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOYEARYKAI4WIQT+4rPRE/wAoxYtYGFSwpQwHqLEkwUCZWuxJl8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0RkVF MkIzRDExM0ZDMDBBMzE2MkQ2MDYxNTJDMjk0MzAxRUEyQzQ5MxAcYXJzZW5AYWFy c2VuLm1lAAoJEFLClDAeosST9zMA/1F8N87E8wsO6ZyuTn2Bi6ynvZ43rJllLjcN ZbvcHxjZAP9o1hYda1/kDWSchD6ugcxOhjuYfEn8FpguYnzmYIUlAw== =Nmwr -----END PGP SIGNATURE----- --=-=-=--