Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 07 Apr 2024 11:05:02 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 278230] sh: Multiple instances overwrite each other's history
Message-ID:  <bug-278230-227@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D278230

            Bug ID: 278230
           Summary: sh: Multiple instances overwrite each other's history
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: bin
          Assignee: bugs@FreeBSD.org
          Reporter: sstj6a2b@eseipi.net

Created attachment 249800
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D249800&action=
=3Dedit
sh: Reload HISTFILE before saving history if necessary

A basic persistent history for sh(1) was implemented in 988b1bb0c54e, but it
doesn't work well when multiple shells coexist at the same time. In additio=
n to
the common and obvious situation with two terminal emulators running
simultaneously (where history from one session will be overwritten entirely=
 by
another), let's consider the following use case: someone starts an X/Wayland
session from a login sh(1) interactively. Then, after logging out, HISTFILE
will contain commands from the tty session only, but not from any other she=
lls
that may have been used.

Steps to reproduce:
1) Start two sh(1) instances.
2) Run "exit 1" in the 1st one. Now the last line of the HISTFILE is "exit =
1".
3) Run "exit 2" in the 2nd one. HISTFILE doesn't contain "exit 1" anymore, =
only
"exit 2".

It happens because sh(1) dumps only history events it has in memory, i.e. t=
hose
loaded from HISTFILE at start plus the ones entered by user in the current
session, but doesn't care that HISTFILE content may have changed in the
meantime.

I wrote a patch that seems to solve the problem for me, but not sure if this
can be considered as expected behavior for anyone else.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-278230-227>