I am working under OS X 10.9.1 (Mavericks), using Terminal, which reports that it is GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)

I noticed some weird issues where history was not working properly: history -a and history -a filename.txt don't do anything. history shows the history I would expect. This breaks my .bashrc synchronization of history across terminals.

I started to investigate by manually changing bash HIST variables. Here is how I am able to reproduce my problem under somewhat controlled conditions:

  1. I disabled my .bashrc
  2. I opened a new terminal window and cleared the history

    history -c
  3. I confirmed that my PROMPT_COMMAND is back to normal/default:


    This returns: update_terminal_cwd;

  4. I manually set the relevant HIST variables:

    export HISTFILE="/Users/rsage/temp_history.txt"
    export HISTSIZE=20000
    export HISTFILESIZE=20000
  5. I confirm my test history files are deleted:

    ls *history*.txt # To make sure I know what I'm about to delete
    rm *history*.txt
  6. I attempt to save the history using history -a with no luck

    history -a
    history -a history_a.txt
    ls -ltr ; date

    This latter shows no history files:

    drwx------+ 40 rsage  staff   1360 Dec 20 14:16 Desktop
    drwxr-xr-x   4 rsage  staff    136 Dec 20 18:48 webApps
    drwxr-xr-x   8 rsage  staff    272 Dec 22 09:11 code
    drwxr-xr-x  17 rsage  staff    578 Dec 22 09:26 stuff

    Sun Dec 22 10:17:50 PST 2013

  7. ...but I stumbled across the history -w command (I know it overwrites the file, which is fine with my nominal bashrc) and this seems to work fine:

    history -w
    history -w history_w.txt
    ls -ltr ; date

    which produces the expected results:

    drwx------+ 40 rsage  staff   1360 Dec 20 14:16 Desktop
    drwxr-xr-x   4 rsage  staff    136 Dec 20 18:48 webApps
    drwxr-xr-x   8 rsage  staff    272 Dec 22 09:11 code
    drwxr-xr-x  17 rsage  staff    578 Dec 22 09:26 stuff
    -rw-------   1 rsage  staff    461 Dec 22 10:19 temp_history.txt
    -rw-------   1 rsage  staff    494 Dec 22 10:19 history_w.txt

One last note. It occurred to me that my sizes might be too large, so I just tried 200 and no change to behavior (the thirties are the history output numbers):

34  export HISTFILESIZE=200
35  export HISTSIZE=200
36  history -a
37  history -a history_a.txt
38  ls -ltr ; date

The ls outputs show no new files.

  • I just repeated the experiment on another computer with OS X 10.8.5, GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin12). I guess it's not Mavericks... – sage Dec 22 '13 at 19:51

I noticed the same odd behavior, checked permissions, and sure enough, both the "World" and "System" had explicit permissions set to read AND write my .bash_history file, but I (the owner) had no permissions to that file at all!

I just forced "World" to "No Access" and gave myself and system r/w access and voila, everything is working the way it should.


I have two answers - why the procedure does not work and why my original problem happened.

history -a issue

In addition to the procedure for repeating this above, I started systematically building my .bashrc up from the ground up. Pretty quickly I determined that it's the history -c that wrecks everything.

If you do the procedure with or without the history -c, you find that history -a works if history -c has not been called in the instance of bash and history -a fails if history -c has been called.

solution to original problem

That answer was not very satisfying - particularly since the issue is that my .bashrc formula relies on history -c as part of propagating history (the standard export PROMPT_COMMAND="history -a; history -c; history -r; $PROMPT_COMMAND" shown at Preserve bash history in multiple terminal windows among other places).

Without fixing this above issue, it seems that the history propagation issue results from using a (relative) path in HISTFILE. HISTFILE seems to want a filename with no path. Thus, changing from HISTFILE="~/.bash_history_shared" to HISTFILE=".bash_history_shared" fixes the original problem.

That raises the obvious question if that would fix the first issue shown above. It seems not to. That being said, the fact that the export PROMPT_COMMAND="history -a; history -c; history -r; $PROMPT_COMMAND" works seems to suggest that perhaps the bizarre to me behavior of history -a is not unusual...?


For El Capitan (10.11.6) I ran into history -a not working - https://unix.stackexchange.com/q/473581/135943

Copying my self-answer from there:

It seems this is something Apple-specific. (I'm using Mac OS 10.11.6 El Capitan.)

My HISTFILE value is the immediate cause:

[512] $ echo $HISTFILE

But since I don't set that variable, where is it being set?

Aha, it's in /etc/bashrc_Apple_Terminal. And from the comments there, it looks like I only ran into this because I tried history -a by itself, without ever setting shopt -s histappend. They've coded it so that if you turn on histappend, or set the HISTTIMEFORMAT variable, they skip the session resume support code.

Here's the inline documentation for that section:

# 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.,
# 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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .