Ho notato lo stesso comportamento strano, i permessi controllati e abbastanza sicuro, sia il "Mondo" che il "Sistema" avevano permessi espliciti impostati per leggere E scrivere il mio file .bash_history, ma io (il proprietario) non avevo i permessi per quello file a tutti!

Ho solo forzato "Mondo" a "Nessun accesso" e ho dato a me stesso accesso al sistema e / o voilà, tutto funziona come dovrebbe.

Ho due risposte: perché la procedura non funziona e perché è successo il mio problema originale.

cronologia: un problema

Oltre alla procedura per la ripetizione di questo, ho iniziato a costruire sistematicamente il mio .bashrc up da zero. Abbastanza rapidamente ho determinato che è il history -c che distrugge tutto.

Se esegui la procedura con o senza history -c , scopri che history -a funziona se history -c non è stato chiamato nell'istanza di bash e history -a fallisce se è stato chiamato history -c .

soluzione al problema originale

Questa risposta non è stata molto soddisfacente, soprattutto dal momento che la mia formula .bashrc si basa su history -c come parte della propagazione della cronologia (lo standard export PROMPT_COMMAND="history -a; history -c; history -r; $PROMPT_COMMAND" mostrato in Conserva la cronologia di bash in più finestre di terminale tra gli altri luoghi).

Senza risolvere questo problema precedente, sembra che il problema di propagazione della cronologia sia dovuto all'utilizzo di un percorso (relativo) in HISTFILE. HISTFILE sembra voler un nome file senza percorso. Pertanto, il passaggio da HISTFILE="~/.bash_history_shared" a HISTFILE=".bash_history_shared" corregge il problema originale.

Ciò solleva l'ovvia domanda se ciò risolvesse il primo problema mostrato sopra. Sembra non farlo. Detto questo, il fatto che il export PROMPT_COMMAND="history -a; history -c; history -r; $PROMPT_COMMAND" funzioni sembra suggerire che forse il comportamento bizzarro di history -a non è insolito ...?

Per El Capitan (10.11.6) mi sono imbattuto in history -a non funzionante - link

Copia la mia auto-risposta da lì:

Sembra che questo sia qualcosa di specifico di Apple. (Sto usando Mac OS 10.11.6 El Capitan.)

Il mio valore HISTFILE è la causa immediata:

[512] $ echo $HISTFILE
/Users/Wildcard/.bash_sessions/8BC6B122-0D74-445B-B6A0-7D4D446598CB.historynew

Ma dal momento che non imposto quella variabile, dove viene impostata?

Aha, è in /etc/bashrc_Apple_Terminal . E dai commenti lì, sembra che mi sia capitato solo perché ho provato history -a da solo, senza mai impostare shopt -s histappend . L'hanno codificato in modo tale che se attivi la riproduzione di ruolo o impostando la variabile HISTTIMEFORMAT, saltano il codice di supporto per riprendere la sessione.

Ecco la documentazione in linea per quella sezione:

# Resume Support: Save/Restore Shell State
#
# Terminal assigns each terminal session a unique identifier and
# communicates it via the TERM_SESSION_ID environment variable so that
# programs running in a terminal can save/restore application-specific
# state when quitting and restarting Terminal with Resume enabled.
#
# The following code defines a shell save/restore mechanism. Users can
# add custom state by defining a shell_session_save_user_state function
# that writes restoration commands to the session file at exit. e.g.,
# to save a variable:
#
#   shell_session_save_user_state() { echo MY_VAR="'$MY_VAR'" >> "$SHELL_SESSION_FILE"; }
#
# During shell startup the session file is executed. Old files are
# periodically deleted.
#
# The default behavior arranges to save and restore the bash command
# history independently for each restored terminal session. It also
# merges commands into the global history for new sessions. Because
# of this it is recommended that you set HISTSIZE and HISTFILESIZE to
# larger values.
#
# You may disable this behavior and share a single history by setting
# SHELL_SESSION_HISTORY to 0. There are some common user customizations
# that arrange to share new commands among running shells by
# manipulating the history at each prompt, and they typically include
# 'shopt -s histappend'; therefore, if the histappend shell option is
# enabled, per-session history is disabled by default. You may
# explicitly enable it by setting SHELL_SESSION_HISTORY to 1.
#
# The implementation of per-session command histories in combination
# with a shared global command history is incompatible with the
# HISTTIMEFORMAT variable--the timestamps are applied inconsistently
# to different parts of the history; therefore, if HISTTIMEFORMAT is
# defined, per-session history is disabled by default.
#
# Note that this uses PROMPT_COMMAND to enable per-session history
# the first time for each new session. If you customize PROMPT_COMMAND
# be sure to include the previous value. e.g.,
#
#   PROMPT_COMMAND="${PROMPT_COMMAND:+$PROMPT_COMMAND; }your_code_here"
#
# Otherwise, the per-session history won't take effect until the first
# restore.
#
# The save/restore mechanism is disabled if the following file exists:
#
#   ~/.bash_sessions_disable