1

This question is related to my question

in KDE under Konsole, when re-opeing a crashed bash shell, how to control what /dev/pts/nn number it gets?

Now again a crash of a shell bash happened by typos.

The bash was running in a window under Konsole in a KDE desktop, as described in previous question.

As a consequence the window was closed and vanished.

In cotrast to former times, now -- after some updatings -- when I re-open the window, the bash in it does not get the same /dev/ptsnn number nn as it was before of the crash, but a new number nn.

This causes that the new bash does not have the same history list as before of the crash.

Thus I struggle with the new problem of how to restore the lost history list.

I have found in the list of running processes given by

ps -AFlwwc

that there exist running bash processes which are

either not attached to a terminal

or attached to ttyS1.

I have to make these bash shell accsessible and reusable.

That may be the crashed shells with their history lists.

How can I do this?

Regards

Improve this question
4
  • Does reptyr help? See this answer and links therein.
    – Kamil Maciorowski
    Commented Jan 30, 2023 at 12:02
  • == to answer of Kamil Marciorowski "reptyr" :: Thanks, this tool was unknown to me. I have installed it. Title of manpage says: "Reparent a running program to a new terminal". This sounds to be just what I need. And the mampage remembered me on the existemce of "ptrace". I will try both. -- Thanks, Regards == 01.02.2023 10:26
    – Anton Wessel
    Commented Feb 1, 2023 at 9:23
  • == 24.02.2023 13:45 (1 of ?) to your very important hint "reptyr", I not clever enough to use it with success. -- As you know, I have in Kubuntu 20.04 and/or KNOPPIX 9.1 KDE running, and under Konsole1, Konsole2, ... terminals with two levels of bash, first level for user-ID 1000, second level for UID 0 = root. -- One such pair of bashs in one terminal happened to become totally dead, could not be closed with Ctrl-C. Thus I was forced to close the window. Re-opening the window arose with a new pts-number, above earlier used numbers and holes inbetween --- will be continued
    – Anton Wessel
    Commented Feb 24, 2023 at 13:01
  • == 24.02.2023 14:05 (2 of ?) not re-opened to pts/1 and Konsole-2, this is the bad behavior of the system since some weeks, what causes that all is lost. So I tried to get some benefit of utility reptyr. One has to give as argument a PID, and I gave $$. But reptyr does not allow to choose the new pts-number. Always a new, a higher one is delivered --- The old, earlier behavor of the system delevered at re-openenig a window the old numbers, in this case should be pts/1 and Konsole-2. --- How can I get back the old behavior of the system as it was since 30 years. -- Regards.
    – Anton Wessel
    Commented Feb 24, 2023 at 13:18

1 Answer 1

Reset to default
0

In cotrast to former times, now -- after some updatings -- when I re-open the window, the bash in it does not get the same /dev/ptsnn number nn as it was before of the crash, but a new number nn.

This causes that the new bash does not have the same history list as before of the crash.

No, it doesn't, and the pty number is irrelevant. Shell input history is not stored within the pty in the first place – it's stored in the shell process while running and written to a file (usually ~/.bash_history) on exit. Even if you do start bash on the same tty or pty as before, it will only know the input history that it reads from ~/.bash_history – there's nothing it could recover from the pty device.

In addition, pseudo-terminals are dynamically allocated, so even if you did get a pty with the same number as before, it would still be a completely new pty. The old pty was deallocated when its "master" process (the terminal emulator) exited and the shell processes that were once attached to terminal are no longer running – they automatically received SIGHUP ("Hangup") upon losing the controlling terminal, just as if you had closed Konsole manually. The default action for shells on SIGHUP is to store the history and exit.

(Bash's default is to completely overwrite history; when using concurrent terminals you probably want to enable the histappend option to avoid one shell overwriting another shell's history file.)

The bash process attached to ttyS1 is a serial-console login. It was definitely not moved from a lost pty to ttyS1; it was always on ttyS1.

Improve this answer
7
  • == comment 1 to answer of "user 1686" == 01.02.2023 11:14 :: thaks for your detailed answer. (1) I always have set "histappend". (2) for some of the cases it is important that I always run two levels of shells bash: first level is what is automatically created when in KDE under Konsole a window is opened. In case of OS KNOPPIX 9.1 this bash is user "knoppix" UID 1000. Thereupon I create a second shell level by "sudo su" or by "/bin/su -c /bin/bash". (continued in next comment)
    – Anton Wessel
    Commented Feb 1, 2023 at 10:44
  • == comment 2 to answer of "user 1686" == 01.02.2023 11:49 :: (3) We have different observations on our different systems, I will refere to :: Signal HUP in the last days gave messages that HUP will cause exit. And it did cause exit for both levels of shell and for vim in it. BUT THE HISTORY LIST WAS NOT WRITTEN TO HISTORY FILE.. (continued in next comment).
    – Anton Wessel
    Commented Feb 1, 2023 at 10:49
  • == comment 3 to answer of "user 1686" == 01.02.2023 11:59 :: (4) Here the case, when the window is deleted by hand. To mention: on the bottom of the screen there is a line with the window tabs. When with the mouse I click on the third tab (from left) I swich to the third window. By default this window has the title bar "Konsole 3". And both levels of bash are attached to "/dev/pts/2". It happens very often that by moving the mouse pointer somehow one of the 10 to 15 windows is removed. Thus the tab vanishes inclusive the two levels of bash and processes running in them (continued in next .
    – Anton Wessel
    Commented Feb 1, 2023 at 11:08
  • == comment 4 to answer of "user 1686" == 01.02.2023 12:15 :: (4) continued. e.g. window 3 is vanished. The history list of bash is not written to history file. Now I have to restore the situation. In any one of the window tabs Iclick right the get the context menu. There I choose "create new window". Now on the most right side of the tab bar a new tab for the new window is creared. And this window has again in the title bar "konsole 3", and the bash is attached again to "/dev/pts/2" as before of the event. And - this is the point - the bash has again its history list. (will be continued).
    – Anton Wessel
    Commented Feb 1, 2023 at 11:40
  • == comment 5 to answer of "user 1686" == 01.02.2023 12:47 :: (4) continued. And - this is the point - the bash has again its history list as before of the event, has NOT the history read from history file. Thus I have only to move the window tab to the old location, third from left. And all is restored, I can continue my work, as if nothing had happened. This was the behavior in all the 30 years. This behavior had changed since some days. I dont know why. (5) Here now the case when I do nothing by hand intentionally but when by typos a bash crashes. (will be continued)
    – Anton Wessel
    Commented Feb 1, 2023 at 12:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .