Z jakiegoś powodu nie mogę zmusić mojego systemu do zachowania historii BASH po ponownym uruchomieniu. Oto odpowiednie sekcje mojego ~/.bashrc
:
shopt -s histappend
PROMPT_COMMAND='history -a; updateWindowTitle'
export HISTCONTROL=ignoredups
export HISTSIZE=9999
export HISTFILESIZE=999999
export HISTFILE="$HOME/.bash_history"
O ile mogę powiedzieć, są to wszystkie niezbędne opcje ( wiem, że kiedyś mogłem przechowywać historię na wielu restartach bez tych wszystkich w przeszłości). Jednak pomimo dodania tych opcji kilka restartów temu, nadal tracę większość historii po ponownym uruchomieniu. Nie jest pusty, ale nie ma linii 9999, które miałem przed ponownym uruchomieniem.
Zanim ktokolwiek narzeka, tak, przeczytałem te pytania. Wdrożyłem niektóre z ich sugestii wymienionych powyżej, pozostałe były albo nieprzydatne, albo nieistotne:
- Utrata historii Bash podczas korzystania z histappend
- Jak zapobiec zmianie historii przez Bash?
- Co decyduje o tym, co pojawia się w poleceniu historii bash?
- Jak zachować moją historię bashów między sesjami?
- regularnie zapisuj historię bash
Jeśli nie ma szans, że mogą tam znajdować się inne odpowiednie polecenia, możesz zobaczyć moją całość ~/.bashrc
tutaj .
Więc czego mi brakuje? Dlaczego moja historia nie jest zapisana? Jeśli ktoś uważa, że inny plik może być odpowiedni, daj mi znać, a ja go opublikuję. Sprawdziłem, uruchamiając grep -i hist \.*
w moim, $HOME
który pokazał, że jedynym odpowiednim .
plikiem zawierającym ciąg hist
lub HIST
był .bashrc
.
Używam Linux Mint Debian Edition, GNU bash, wersja 4.2.36 (1) -release (x86_64-pc-linux-gnu) i mój ulubiony emulator terminala (jeśli jest to istotne) terminator
.
AKTUALIZACJA:
Podążając za sugestią @ mpy w komentarzach, zmieniłem ~/.bashrc
ustawienie HISTFILE=~/bash_history
na przeciwne do domyślnego ~/.bash_history
i wydaje się, że to rozwiązuje problem interaktywnych powłok . Powłoki logowania nadal wyświetlają to samo zachowanie, a historia jest obcinana w 500
wierszach. Jednak HIST
w odpowiednich plikach nie ma powiązanych zmiennych:
$ for f in /etc/profile ~/.profile ~/.bash_profile ~/.bash_login; do \
echo -ne "$f :"; echo `grep HIST $f`; \
done
/etc/profile :
/home/terdon/.profile :grep: /home/terdon/.profile: No such file or directory
/home/terdon/.bash_profile :grep: /home/terdon/.bash_profile: No such file or directory
/home/terdon/.bash_login :grep: /home/terdon/.bash_login: No such file or directory
$ grep -r HIST /etc/profile.d/ <-- returns nothing
Więc dlaczego jest ustawienie HISTSIZE
i HISTFILESIZE
w ~/.bashrc
nie na tyle, chyba że wyraźnie ustawić $HISTFILE
się do czegoś innego niż domyślny ~/.bash_history
?
history
polecenie, wynik, który widzisz, jest identyczny z tym, co widzisz, działającymcat .bash_history
, innym niż numery linii? Mam na myśli, czyhistory
znaczniki czasu listy poleceń lub inne informacje? Pytam dlatego, że jeśli widzisz te ezoteryczne rzeczy, oznacza to, że istnieje inny moduł / funkcja / program, który psuje się z historią powłoki i zła lub błędna wersja tego, co jest, może powodować ci smutek .;)
: Wypróbuj inny plik jako HISTFILE, a nie domyślny~/.bash_history
. Bardzo skonstruowane wyjaśnienie: Zakładam, że bash jest domyślną powłoką, więc po uruchomieniu systemu powłoka nieinteraktywna jest rodzicem sesji X (zakładam również, że używasz X), który nie będzie wiedział nic o opcji histappend (ponieważ .bashrc jest tylko czytane przez interaktywne powłoki), więc tak długo, jak ta macierzysta powłoka działa, wszystko jest w porządku, ale po zakończeniu (tj. zatrzymaniu systemu) zastąpi~/.bash_history
(co jest domyślne) iOdpowiedzi:
Problem w rzeczywistości sprowadza się do różnych zachowań powłok logowania i bez logowania. Ustawiłem zmienne, które kontrolują historię w moim
~/.bahsrc
. Ten plik nie jest odczytywany po uruchomieniu powłoki logowania, jest odczytywany tylko przez interaktywne powłoki niezalogowane (zman bash
):Dlatego za każdym razem, gdy logowałem się, upuszczałem na tty lub korzystałem z ssh,
.history
plik był obcinany, ponieważ nie ustawiłem go również we właściwym rozmiarze~/.profile
. W końcu zdałem sobie z tego sprawę i po prostu ustawiłem zmienne~/.profile
tam, gdzie należą , zamiast~/.bashrc
Dlatego
~/.history
zostałem obcięty, ponieważ ustawiłem tylko zmienne HISTORY w pliku odczytywanym przez interaktywne powłoki bez logowania i dlatego za każdym razem, gdy uruchamiam inny typ powłoki, zmienne byłyby ignorowane i plik byłby cięty odpowiednio.źródło
.bashrc
nie jest odczytywany przez (nieinteraktywne powłoki logujące LUB).export BASH_ENV=~/.bashrc ; if [ -f ~/.bashrc ]; then . ~/.bashrc; fi
... i na górze ~ / .bashrc zaznaczyć, aby upewnić się, że naprawdę działasz interaktywnie:[ -z "$PS1" ] && return
... Oczywiście to tylko idiom.BASH_ENV
nie jest istotny, dotyczy tylko nieinteraktywnych powłok. Jeśli chodzi o „idiom”, jest to coś, co rozpoczął Debian iz którym osobiście się nie zgadzam. Często mam opcje graficzne (xset
i tym podobne) w moim .bashrc i nie chcę, aby były one aktywne, gdy uruchamiam powłoki logowania od tty lub przezssh
. Chcę, aby mój .profile i .bashrc były osobne. Wiele (choć nie wszystkie) menedżerów logowania źródłowych .profile podczas logowania, więc zmienne globalne najlepiej ustawić tam, gdzie będą odczytywane tylko raz, a nie przy każdym otwarciu terminala.~/.profile
lub~/.bashrc
) są odczytywane na końcu. Wszystko, co zostanie w nich ustawione, będzie miało pierwszeństwo przed ustawieniami globalnymi. Masz całkowitą rację, nie powinieneś ustawiać tych zmiennych/etc/bash.bashrc
. Zamiast tego użyj~/.profile
(lub~/.bash_profile
).Moją sugestią jest użycie innego pliku, a
HISTFILE
nie domyślnego~/.bash_history
.Chociaż nie mam analitycznego wyjaśnienia, postaram się nakreślić, co doprowadziło mnie do tej sugestii: jeśli użyjesz
bash
jako domyślnej powłoki (logowania), a także użyjeszX
(co jest bardzo prawdopodobne), masz działającąbash
instancję zaraz po (graficznym ) Zaloguj sie:Myślę, że to wystąpienie jest powłoką logowania, więc nie odczytuje twojej,
~/.bashrc
a zatem nie będzie wiedzieć o tejhistappend
opcji:Tak długo, jak działa ta „nadrzędna powłoka”, wszystko jest w porządku, ale po jej zakończeniu (tj. Zatrzymaniu systemu) będzie ona nadpisywać
~/.bash_history
(ponieważ jest to wartość domyślna) i popsunie historię lub przycina ją w systemie, aby zacząć (ponownie domyślnie) 500 linie. (A może oba ...)Uderza mnie również to, że nie wystarczy dołączyć konfigurację historii
~/.bashrc
, ponieważ nie powinna to być tak rzadka konfiguracja. Nie mam na to wytłumaczenia.Jeśli chodzi o problem polegający na tym, że „Powłoki logowania nadal wyświetlają to samo zachowanie”, możesz spróbować dołączyć konfigurację historii również do
~/.bash_profile
:Niestety nie mogę opublikować bardziej uzasadnionego wyjaśnienia ze szczegółami z mojej własnej
bash
konfiguracji, ponieważ jestemzsh
facetem ...źródło
~/.bash_profile
rozwiązało problem. Używam teraz~/.bash_history
jako pliku historii, ale po prostu dodałem wszystkie wiersze z~/.bashrc
pokazanego w moim pytaniu do~/.bash_profile
. Nadal nie jestem pewien, kto spieprzył interaktywne muszle, ale wydaje się, że teraz działa, dzięki!Ponieważ wszystkie ustawienia są uporządkowane według strony podręcznika i ponieważ plik historii nie jest ograniczony rozmiarem (bajtami), jedyne możliwe wyjaśnienie, jakie mogę wymyślić. Ma to związek z tym, jak umiera skorupa.
Zgodnie z odniesieniem online wdzięczne wyjście (zapisana historia) następuje tylko wtedy, gdy powłoka otrzymuje SIGHUP. Naprawdę nie potrafię wyjaśnić, w jaki sposób twój system propaguje sygnały po ponownym uruchomieniu, ale podejrzewam, że twoja powłoka kończy pracę z SIGKILL lub SIGPWR.
Może to być spowodowane tym, że WM działa asynchronicznie (poczekaj), a emulator terminala odrodził się z WM, gdzie bash otrzymuje sygnał wymuszający wyjście inny niż SIGHUP. Może się również zdarzyć, że system operacyjny szybko wyśle „ostateczne zabójstwo” do wszystkich procesów, zanim początkowy wdzięczny SIGHUP zdoła dostać się do powłoki przez X -> WM -> xterm, być może dlatego, że X lub WM trwa dłużej niż wyjście niż system operacyjny musi być gotowy do upadku.
Jestem na głębokich wodach z tymi rzeczami, ale myślę, że coś w tym stylu powoduje nieprawidłowe zachowanie. Miałem już ten problem, a najbardziej solidnym lekarstwem jest
exit
bash, w którym chcesz zachować historię.Zauważyłem
history -a
w twoim pytaniu i nie mogę wymyślić, dlaczego to nie wystarczyłoby, aby zachować historię.Możesz rozwiązać problem, zastanawiając się, co tak naprawdę zabija twój bash, i przechodząc do ustalenia źródła sygnału i naprawiając problem, lub po prostu opróżnij historię, gdy wiesz, który sygnał jest ostatni (zakładając, że dyski są nadal online ):
Załączony zrzut ekranu ilustruje to, o czym mówię w akapitach drugim i trzecim. Sekwencja, w której ja strzelam z lewej , zabij lewą z prawej i przeglądaj historię.
uderzenie człowieka
referencje online
przykładowy zrzut ekranu
źródło
/tmp/pso
zabijasz? Rozumiem twój punkt widzenia na temat różnych sygnałów zabicia (choć, jak mówisz, myślałem, że właśnie ohistory -a
to chodzi). Przetestuję to przez chwilę i zdam relację.Sprawdź / etc / profile i /etc/profile.d/*
Może jest tam coś nie tak z ustawieniami historii.
źródło
grep -r HIST /etc/profile.d/
nic nie zwraca, a ja już sprawdziłem/etc/profile
.