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

Anton Wessel
  • 161

1 Answers1

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.

grawity
  • 501,077