Po dowiedzeniu się, co to shopt -s histappend oznacza , wydaje się to bardzo rozsądne ustawienie i jestem zaskoczony, że nie jest to ustawienie domyślne. Dlaczego ktoś miałby wymazać swoją historię przy każdym wyjściu z powłoki?
Po dowiedzeniu się, co to shopt -s histappend oznacza , wydaje się to bardzo rozsądne ustawienie i jestem zaskoczony, że nie jest to ustawienie domyślne. Dlaczego ktoś miałby wymazać swoją historię przy każdym wyjściu z powłoki?
Odpowiedzi:
Cóż, gdy histappendnie jest ustawione, nie oznacza to, że historia jest czyszczona przy każdym wyjściu z powłoki. Bez histappendbash odczytuje plik histogramu przy uruchamianiu do pamięci - podczas operacji dodawane są nowe wpisy - a przy wyjściu z powłoki ostatnie wiersze HISTSIZE są zapisywane do pliku historii bez dołączania, tj. Zastępując poprzednią zawartość.
Na przykład, jeśli plik histetyczny zawiera 400 wpisów, w czasie wykonywania bash zostanie dodanych 10 nowych wpisów - rozmiar histerezy jest ustawiony na 500, a następnie nowy plik histetyczny zawiera 410 wpisów.
To zachowanie jest problematyczne tylko wtedy, gdy używasz większej liczby wystąpień bash równolegle. W takim przypadku plik historii zawiera tylko zawartość ostatniej wychodzącej powłoki.
Niezależnie od tego: są ludzie, którzy ze względów prywatności chcą wyczyścić swoją historię przy wyjściu z powłoki.
histappendma jakiekolwiek znaczenie dla tego root, czy historia sięga dysku? Ponownie wpływa to tylko na to, co jest napisane, a nie jeśli .
histappenda także HISTCONTROL=ignoredups:erasedups:ignorespacewydaje się być dobrym rozwiązaniem dla większości ludzi.
histappendskuteczne jest bez znaczenia, jeśli mam HISTFILESIZE=i HISTSIZE=dla nieskończonej historii?
Chyba dla historycznej zgodności. Ta histappendopcja nie istniała do momentu bash 2.0.
histappend.
bash„czysty” lub dostarczony z dystrybucją.bashrc. w przypadku tych pierwszych @Gilles jest prawdopodobnie poprawny. w tym drugim sensie domyślnie-s histappendjest stosowany np. w Debianie od 2008: bugs.debian.org/cgi-bin/bugreport.cgi?bug=452459