Perdita della cronologia di Bash durante l'utilizzo di histappend

18

Mi piace conservare molta storia, quindi mi sono histappendambientato nel mio .bashrc. Il più delle volte tutto funziona bene, con la storia costruita da molte shell che si aggiungono. Tuttavia, ogni tanto, inizio una nuova shell e scopro di aver perso l'intera cronologia - e spesso contiene solo alcuni dei comandi dell'ultima shell per uscire (ovvero non è solo sovrascrivere invece di aggiungere ). Per questo motivo, sospetto che stia accadendo all'uscita della shell, piuttosto che da qualche altro processo che sta uccidendo il .bash_historyfile. A sostegno di questa conclusione, ho dei numeri di comando storici nel mio prompt e non li ho mai visti saltare giù.

Qualcuno ha mai incontrato un problema simile? O hai solo dei suggerimenti su come rintracciare il problema?

bash history

— Cascabel
fonte

1

Vedi: patch # 8676: Correzione del troncamento di .bash_history

— kenorb,

13

Mi dispiace rispondere alla mia domanda, ma nessuna delle altre risposte risolve davvero il problema.

Ho finalmente capito che questo accade solo quando si chiude gnome-terminalse stesso (cioè file> esci, il pulsante 'x', alt + F4), e anche in genere solo quando si chiudono più terminali in rapida successione. Non succede mai quando si usa ctrl-D per chiudere la shell, lasciando che il terminale segua.

Se riesco a fissarlo abbastanza bene, presenterò un rapporto sui bug di gnome-terminal. Nel frattempo, forse questo aiuterà alcune altre persone che arrivano qui da Google!

— Cascabel
fonte

10

Non ho idea del perché ciò accada, ma forse puoi aggirare il problema forzando bash a scrivere nel suo file di cronologia ogni volta che visualizza un prompt:

PROMPT_COMMAND="history -a; history -n"

Questo scriverà (-a) e quindi rileggerà (-n) il file della cronologia ogni volta che bash richiede il comando successivo. Vantaggio aggiuntivo: otterrai il comando X nella shell 1 nella storia della shell 2.

— innaM
fonte

Non funziona su GNU bash, versione 3.00.15 (1) -release (i686-redhat-linux-gnu)

— David Mackintosh,

2

Puoi spiegare cosa significa "non funziona"?

— innaM

3

Il vantaggio aggiuntivo che citi è in molti casi un aspetto negativo. Non è il comportamento che sto cercando, poiché potrei svolgere due compiti completamente separati in shell separate e non voglio mescolare la loro storia. Anche questo probabilmente non aiuterebbe nulla. Quando la cronologia scompare, sta eliminando il contenuto di .bash_history: non mi aspetto che importi se sono stati scritti all'uscita della shell o da PROMPT_COMMAND.

— Cascabel,

5

history -nè traballante. È più affidabile da fare history -a; history -c; history -r. Per spiegarlo, noterò innanzitutto che history -afa la cosa giusta - il tuo .bash_historyconterrà tutti i tuoi comandi digitati, nell'ordine in cui li hai digitati - supponendo che tu esegua history -adopo ogni comando. La sfida è mantenere sincronizzata l'idea della storia della shell con il file .bash_history. Questo è facile con -ce -r, il problema è che potrebbe essere lento se è grande. -npuò rompersi perché identifica erroneamente quali righe sono nuove. (Sto esaurendo lo spazio qui!)

— Aaron McDaid l'

4

(... se usate -n) Immaginate si esegue un comando in guscio 1: ls. Quindi in un'altra shell, Shell Two, esegui cd. Ora, la cronologia in .bash_history è corretta a causa di history -ain your PROMPT_COMMAND- conterrà ls \n cd \n. Successivamente, si ritorna alla shell One e si digita pwd. Shell One pensa che ci fosse solo il comando nella storia ( ls). Ora pensa che ci siano due comandi ( lse pwd) nella storia. Quando lo fai -npensa (ho due comandi nella mia storia e ci sono due comandi in .bash_history, quindi sono aggiornato.)

— Aaron McDaid l'

3

La mia esperienza è stata che le shell hanno aggiornato il file della cronologia al momento dell'uscita. Quindi la "storia" iniziale di una shell dipendeva dalla visione della storia della shell più recente.

Il risultato è che puoi ottenere comandi che vanno e vengono dalla cronologia, a seconda di come sono iniziate e arrestate le altre shell.

— David Mackintosh
fonte

2

Capisco molto bene come viene scritto il file della cronologia - ecco perché ho specificato nella mia domanda che sto usando histappend. Il problema non è il contenuto imprevisto, ma una perdita totale di contenuto precedentemente memorizzato.

— Cascabel,

Questo spiega perché stavo perdendo la mia storia ...

— B Seven,

1

L'ho visto accadere prima, ma era un problema con errori del disco che si stavano verificando con frequenza crescente. Vorrei eseguire una scansione sull'unità. Se si scopre che l'unità va bene, vorrei verificare se questo file non sta superando un limite di cronologia della shell arbitrario.

Qualcosa che potrebbe essere in grado di impedire che ciò accada sarebbe quello di continuare a potare il file di nuovo a 80 righe o per quanto molti comandi si desideri siano la cronologia.

— Axxmasterr
fonte

Non ho accesso root sulla macchina su cui sta succedendo, ma sono abbastanza sicuro che l'unità sia ok. La mia directory home è memorizzata su un server nel nostro laboratorio (credo che sia pieno di RAID) e montata su nfs. Cosa intendi con "limite di cronologia shell arbitrario"? Tutto questo sta succedendo ben al di sotto di HISTSIZE e HISTFILESIZE, e sebbene sia stato impostato grande, sono ben al di sotto della base int.

— Cascabel,

Devo dire che l'ingresso di David Mackintosh è probabilmente ciò che sta accadendo.

— Axxmasterr,

1

Sono assolutamente sicuro che non lo sia. Non dovrei mai finire con solo due comandi nella mia storia, quando l'ultima shell per uscire aveva una dozzina di comandi, il file della cronologia ne aveva diverse centinaia e HISTSIZE / HISTFILESIZE sono impostati su 10000.

— Cascabel