Noté el mismo comportamiento extraño, revisé los permisos y, efectivamente, tanto el "Mundo" como el "Sistema" tenían permisos explícitos establecidos para leer Y escribir mi archivo .bash_history, pero yo (el propietario) no tenía permisos para eso archivo en absoluto!

Acabo de forzar "Mundo" a "Sin acceso" y me di a mí mismo y al sistema r / w acceso y listo, todo funciona como debería.

Tengo dos respuestas: por qué el procedimiento no funciona y por qué ocurrió mi problema original.

historial -un problema

Además del procedimiento para repetir esto anteriormente, comencé a construir sistemáticamente mi .bashrc desde cero. Muy rápidamente determiné que es el history -c lo que destruye todo.

Si realiza el procedimiento con o sin el history -c , encontrará que history -a funciona si no se ha llamado a history -c en la instancia de bash y history -a falla si se ha llamado a history -c .

solución al problema original

Esa respuesta no fue muy satisfactoria, especialmente porque el problema es que mi fórmula .bashrc se basa en history -c como parte del historial de propagación (el estándar export PROMPT_COMMAND="history -a; history -c; history -r; $PROMPT_COMMAND" se muestra en Preserve bash history en múltiples ventanas de terminal entre otros lugares).

Sin solucionar este problema anterior, parece que el problema de propagación del historial resulta de usar una ruta (relativa) en HISTFILE. HISTFILE parece querer un nombre de archivo sin ruta. Por lo tanto, al cambiar de HISTFILE="~/.bash_history_shared" a HISTFILE=".bash_history_shared" se soluciona el problema original.

Eso plantea la pregunta obvia si eso solucionaría el primer problema que se muestra arriba. Parece que no Dicho esto, el hecho de que export PROMPT_COMMAND="history -a; history -c; history -r; $PROMPT_COMMAND" funcione parece sugerir que tal vez el extraño comportamiento de history -a no sea inusual ...?

Para El Capitán (10.11.6) me encontré con history -a que no funciona - enlace

Copiando mi auto-respuesta desde allí:

Parece que esto es algo específico de Apple. (Estoy usando Mac OS 10.11.6 El Capitán.)

Mi valor HISTFILE es la causa inmediata:

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

Pero como no configuro esa variable, ¿dónde se configura?

Ajá, está en /etc/bashrc_Apple_Terminal . Y a partir de los comentarios, parece que solo me topé con esto porque probé history -a por sí mismo, sin haber configurado nunca shopt -s histappend . Lo han codificado para que si activa histappend, o configura la variable HISTTIMEFORMAT, omita el código de soporte de reanudación de sesión.

Aquí está la documentación en línea para esa sección:

# 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