Das Problem läuft tatsächlich auf das unterschiedliche Verhalten von Login- und Nicht-Login-Shells hinaus. Ich hatte die Variablen, die den Verlauf steuern, in meinem ~/.bahsrc gesetzt . Diese Datei wird nicht gelesen, wenn man eine Login-Shell startet, sie wird nur von interaktiven Nicht-Login-Shells gelesen (ab man bash ):
Wenn bash als interaktive Login-Shell oder als nicht-interaktive Shell mit --login aufgerufen wird Option, liest und führt es zuerst Befehle aus der Datei /etc/profile aus , wenn diese Datei existiert. Nach dem Lesen dieser Datei sucht es nach ~/.bash_profile,~/.bash_login , und ~/.profile , in dieser Reihenfolge, und liest und führt Befehle aus dem ersten Befehl aus, der vorhanden und lesbar ist. Die --noprofile Option kann verwendet werden, wenn die Shell gestartet wird, um dieses Verhalten zu verhindern.
[. . . ]
Wenn eine interaktive Shell, die keine Login-Shell ist, gestartet wird, liest und führt bash Befehle aus ~/.bashrc aus, falls diese Datei existiert. Dies kann durch die Verwendung der Option --norc verhindert werden. Die Dateioption --rcfile zwingt Bash dazu, Befehle aus der Datei statt aus ~/.bashrc.
zu lesen und auszuführen
Daher wurde jedes Mal, wenn ich mich anmeldete oder zu einem tty wechselte oder ssh benutzte, der .history Datei wurde abgeschnitten, weil ich sie in ~/.profile nicht auf die richtige Größe eingestellt hatte auch. Ich habe das endlich erkannt und die Variablen einfach in ~/.profile gesetzt wohin sie gehören, statt ~/.bashrc
Also, der Grund ist mein ~/.history abgeschnitten wurde, lag daran, dass ich die HISTORY-Variablen nur in einer Datei gesetzt hatte, die von interaktiven Nicht-Login-Shells gelesen wurde, und daher jedes Mal, wenn ich einen anderen Shell-Typ ausführte, die Variablen ignoriert und die Datei entsprechend gekürzt wurden.
Mein Vorschlag ist, eine andere Datei als HISTFILE zu verwenden , nicht der Standardwert ~/.bash_history .
Obwohl ich keine analytische Erklärung habe, werde ich versuchen zu skizzieren, was mich zu diesem Vorschlag geführt hat:Wenn Sie bash verwenden als Ihre Standard-(Anmelde-)Shell und verwenden Sie auch X (was beides sehr wahrscheinlich ist) Sie haben einen laufenden bash Instanz direkt nach dem (grafischen) Login:
systemd
...
|-login
| `-bash <<====
| `-slim
| |-X -nolisten tcp vt07 -auth /var/run/slim.auth
| | `-{X}
| `-fluxbox
| `-xterm -bg black -fg white
| `-bash
...
Ich denke, diese Instanz ist eine Login-Shell, also liest sie Ihren ~/.bashrc nicht und weiß daher nichts über histappend Möglichkeit:
man bash(1) :Wenn eine interaktive Shell kein Login ist Shell gestartet wird, liest und führt die Bash Befehle aus /etc/bash.bashrc und ~/.bashrc aus, falls diese Dateien existieren. (...)
Solange diese "Eltern-Shell" läuft, ist alles in Ordnung, aber bei ihrer Beendigung (d. h. Systemhalt) überschreibt sie ~/.bash_history (weil das der Standardwert ist) und Ihren Verlauf durcheinander bringt oder ihn beim Systemstart auf (wieder Standard) 500 Zeilen kürzt. (Oder vielleicht beides...)
Mir fällt auch auf, dass es nicht ausreicht, die Verlaufskonfiguration in ~/.bashrc aufzunehmen , da dies kein so ungewöhnliches Setup sein sollte. Dafür habe ich keine Erklärung.
Bezüglich Ihres Problems, dass "Login-Shells immer noch das gleiche Verhalten zeigen", können Sie versuchen, die Verlaufskonfiguration auch in ~/.bash_profile aufzunehmen :
man bash(1) :Wenn bash als interaktive Login-Shell oder als nicht-interaktive Shell mit der Option --login aufgerufen wird, liest es zuerst Befehle aus der Datei /etc/profile und führt sie aus, falls diese Datei existiert. Nach dem Lesen dieser Datei sucht es nach ~/.bash_profile, (...)
Leider kann ich keine begründetere Erklärung mit Details aus meinem eigenen bash posten config, da ich ein zsh bin Typ...
Da alle Ihre Einstellungen gemäß der Manpage in Ordnung sind und die Verlaufsdatei nicht auf die Größe (Bytes) beschränkt ist, ist die einzig mögliche Erklärung, die mir einfällt. Es hat damit zu tun, wie die Schale stirbt.
Gemäß der Online-Referenz tritt der ordnungsgemäße Ausgang (Verlauf gespeichert) nur auf, wenn die Shell SIGHUP empfängt. Ich kann nicht wirklich erklären, wie Ihr System beim Neustart Signale weiterleitet, aber ich vermute, dass Ihre Shell mit SIGKILL oder SIGPWR beendet wird.
Es könnte daran liegen, dass Ihr WM asynchron läuft (warten) und der Terminal-Emulator, der aus dem WM hervorgegangen ist, in dem sich bash befindet, ein anderes Exit-Erzwingungssignal als SIGHUP erhält. Es könnte auch sein, dass das Betriebssystem zu schnell ist, um den "final kill" an alle Prozesse zu senden, bevor das anfängliche anmutige SIGHUP es schafft, über X -> WM -> xterm zur Shell zu gelangen, möglicherweise weil X oder WM länger zum Beenden brauchen als Es dauert, bis das Betriebssystem bereit ist, herunterzufahren.
Ich bin mit diesem Zeug auf tiefem Wasser, aber ich denke, etwas in dieser Richtung verursacht das unberechenbare Verhalten. Ich hatte dieses Problem schon einmal und die zuverlässigste Abhilfe ist exit in Bash, wo Sie die Geschichte behalten möchten.
Ich habe history -a bemerkt in Ihrer Frage, und ich kann mir nicht vorstellen, warum das nicht ausreichen würde, um die Geschichte zu bewahren.
Sie können das Problem beheben, indem Sie herausfinden, was Ihre Bash wirklich tötet, und dann herausfinden, woher das Signal stammt, und das Problem dort beheben, oder einfach den Verlauf leeren, wenn Sie wissen, welches Signal das letzte ist (vorausgesetzt, die Festplatten sind bis dahin noch online). ):
trap "echo got 1 >/tmp/sig1; exit" SIGHUP
trap "echo got 2 >/tmp/sig2; exit" SIGINT
trap "echo got 15 >/tmp/sig15; exit" SIGTERM
.. and so on...
Der beigefügte Screenshot veranschaulicht, wovon ich im zweiten und dritten Absatz spreche. Die Sequenz dort ist I shell in von links , töte die linke Muschel von rechts und katze die Geschichte.
Männerschlag
Beim Start (...) wird die durch den Wert von HISTFILE benannte Datei ggf. so gekürzt, dass sie nicht mehr als die durch den Wert von HISTFILESIZE angegebene Anzahl von Zeilen enthält (+ Standardwert 500).
Wenn die Shell-Option histappend aktiviert ist (hier standardmäßig aktiviert), werden die Zeilen an die Verlaufsdatei angehängt, andernfalls wird die Verlaufsdatei überschrieben.
Online-Referenz
3.7.6 Signale
Wenn Bash interaktiv ist und keine Traps vorhanden sind, ignoriert es SIGTERM (damit „kill 0“ keine interaktive Shell beendet) und SIGINT wird abgefangen und verarbeitet (damit das eingebaute Wait unterbrechbar ist). Wenn Bash ein SIGINT empfängt, bricht es aus allen ausgeführten Schleifen aus. In allen Fällen ignoriert Bash SIGQUIT. Wenn Jobkontrolle aktiv ist (siehe Jobkontrolle), ignoriert Bash SIGTTIN, SIGTTOU und SIGTSTP.
Nicht eingebaute Befehle, die von Bash gestartet werden, haben Signal-Handler, die auf die Werte gesetzt sind, die die Shell von ihrem übergeordneten Element geerbt hat. Wenn die Jobsteuerung nicht aktiv ist, ignorieren asynchrone Befehle SIGINT und SIGQUIT zusätzlich zu diesen geerbten Handlern. Befehle, die als Ergebnis der Befehlsersetzung ausgeführt werden, ignorieren die von der Tastatur generierten Auftragssteuersignale SIGTTIN, SIGTTOU und SIGTSTP.
Die Shell wird standardmäßig beim Empfang eines SIGHUP beendet. Vor dem Beenden sendet eine interaktive Shell das SIGHUP erneut an alle laufenden oder angehaltenen Jobs. Gestoppte Jobs erhalten SIGCONT, um sicherzustellen, dass sie das SIGHUP erhalten. Um zu verhindern, dass die Shell das SIGHUP-Signal an einen bestimmten Job sendet, sollte er mit dem Disown-Built-in aus der Jobs-Tabelle entfernt werden (siehe Job Control Built-Ins) oder mit disown -h so markiert werden, dass er kein SIGHUP-Signal empfängt.
Wenn die huponexit-Shell-Option mit shopt gesetzt wurde (siehe Shopt Builtin), sendet Bash ein SIGHUP an alle Jobs, wenn eine interaktive Login-Shell beendet wird.
Wenn Bash auf den Abschluss eines Befehls wartet und ein Signal empfängt, für das ein Trap gesetzt wurde, wird der Trap nicht ausgeführt, bis der Befehl abgeschlossen ist. Wenn Bash über das Wait-Built-In auf einen asynchronen Befehl wartet, führt der Empfang eines Signals, für das ein Trap gesetzt wurde, dazu, dass das Wait-Built-In sofort mit einem Exit-Status größer als 128 zurückkehrt, woraufhin das Trap ausgeführt wird.
demonstrativer Screenshot
