Apple Terminal startup errors (session save/restore)

(This issue has also been reported on Stack Overflow and discussions.apple.com, as well as Feedback Assistant. Hope it’s not inappropriate to post here.)

(TL; DR: If you’re even an occasional user of the stock Apple Terminal app, it would be useful to know if you experience this. You need to have macOS set to restore apps’ windows, and have more than one terminal window or tab open when you quit. I have seen this in a new virtual machine, indicating it’s a pervasive issue.)

Recently (but not clear how recently since it’s not tied to a specific macOS release), Apple Terminal has been giving the following error on startup (when macOS is set to restore windows, i.e., when System Settings > Close windows when quitting… is unset):

date: illegal time format
usage: date [-jnRu] [-I[date|hours|minutes|seconds]] [-f input_fmt]
            [-r filename|seconds] [-v[+|-]val[y|m|w|d|H|M|S]]
            [[[[mm]dd]HH]MM[[cc]yy][.SS] | new_date] [+output_fmt]
-bash: Saving: command not found

I have traced this to an error coming from /etc/bashrc_Apple_Terminal which is largely concerned with saving and restoring sessions for the various terminal tabs and windows.

It comes from the lines

    if [ -r "$SHELL_SESSION_FILE" ]; then
	. "$SHELL_SESSION_FILE"
	rm "$SHELL_SESSION_FILE"
    fi

On shell startup, this snippet runs, and then deletes, "$SHELL_SESSION_FILE", which is written at shell exit by the following lines:

	if [ -n "$SHELL_SESSION_FILE" ]; then
	    echo -ne '\nSaving session...' >&2
	    (umask 077; echo 'echo Restored session: "$(/bin/date -r '$(/bin/date +%s)')"' >| "$SHELL_SESSION_FILE")
	    declare -F shell_session_save_user_state >/dev/null && shell_session_save_user_state
	    shell_session_history_allowed && shell_session_save_history
	    echo 'completed.' >&2
	fi

The error occurs because $SHELL_SESSION_FILE in ~/bash_sessions/ contains the following incorrect text:

Saving session...echo Restored session: "$(/bin/date -r 1698759014 Saving session...)"

rather than the expected echo Restored session: "$(/bin/date -r 1698759014)
For some reason, the Saving session... text is appearing in the file (twice!).

The code is run via trap shell_session_update EXIT. The error only seems to happen when I exit the shell by quitting Terminal.app, but not when I just use the exit command. (And I’ve even tried explicitly sending various signals to the shell via kill -n, but I can’t seem to induce the error that way.) There is some evidence that it is a race condition of some sort, only occurring when there is more than one terminal window or tab open when the Terminal app is quit. (One of the SO answers has a modification to /etc/bashrc_Apple_Terminal which fixes the problem, but this may be just a band-aid over the symptom rather than the underlying cause.)

The error spans multiple versions of macOS, both intel and Apple Silicon, and a similar error appears with zsh rather than bash, and the error has been seen by others. There does not appear a single piece of software common to everyone who has seen the problem. (Suggested causes have included homebrew, Python, VS Code. I have removed /opt/homebrew and rebooted and am still seeing the issue (but I haven’t tried with a completely pristine system. Is it possible that any of these things somehow “pollutes” the environment – e.g., /etc/ – in some way that remains in place?)

I can’t tell if the error is very common but just not reported, since indeed whenever I’ve had an opportunity to ask a colleague about it, they have inevitably been able to reproduce the bug on their own machines. (But in this case I would expect it to be common with Apple employees, and hence something in line to be fixed…)

Is anyone (everyone?) else seeing this? Any ideas beyond the brittle /etc/bashrc_Apple_Terminal fix?

I still use bash as my default shell across multiple Macs and macOS versions, and I always use the save/restore session function. I typically have two or more Terminal.app windows open at a time, and I have never seen the error.

I haven’t used homebrew or other third-party customizations to my shell environment in a very long time, so I suspect the issue indeed lies with third-party software or other customizations. My only customizations are fairly basic modifications to ~/.bash_profile.

1 Like

I’m not seeing this either with zsh on “fairly stock” M1 Mac mini running Sonoma. I have MacPorts (not Homebrew) installed and there doesn’t appear to be any malevolent interactions.

Very strange indeed.

Has this been checked out with a newly created user account?

I suspect something in the user environment. Examining the environment settings compared to a freshly installed, standalone system may yield a clue.

1 Like

Ok, interesting to know that this is not universal. For what it’s worth, it does seem to happen for new users, so not necessarily related to a user’s own setup. I haven’t had access to a pristine machine in order to test it yet more thoroughly, alas.

Anyone else out there in TB land seeing this?

If you have a system with sufficient capacity, perhaps you could set up a virtual machine for testing purposes.

That’s actually a good idea. If you’re on an Apple Silicon Mac, install the free version of UTM. You don’t need a lot of resource (I’ve done this on an 8GB Mac mini M1 - and setting a VM for 4GB of memory will get macOS installed and running to a point where you could test something like this).

Ok so I tried this (using Howard Oakley’s excellent sandboxed lightweight VM, ViableS).

I have installed nothing, nada, zip, and added no files to ~/ or anywhere else.

However, after starting and restarting Terminal.app with a few tabs, and ensuring that “close windows when quitting” is unset, I immediately got the message

/Users/jaffe/.zsh_sessions/<random hex guid>.session:2: command not found: Saving

I haven’t used a vm before, but I don’t think there is any possible pollution from my host environment (I specifically chose the “Sandboxed” version of the app to be extra sure!).

So, with all due respect to anyone who doesn’t see this issue: how is this possible???

By “a few tabs”, how many are “a few”? Knowing the exact steps you took to reproduce the issues would help us try to see if we can reproduce it as well.

And is there anything running in those tabs at the time you’re closing the Terminal app?

Usually you’re not carrying anything account related over into a new VM so I wouldn’t be worried about any pollution from the host. I’m assuming you’ve created brand new fresh accounts.

This is very bizarre, since the writing of the Saving session… text is going to standard error. Somehow that’s going as well to the $SHELL_SESSION_FILE which I would not expect given the code fragments I’m seeing.

My immediate guess is that this is a timing/race issue based on the number of tabs/windows you have open in Terminal. That’s why the exact steps you took to reproduce in the VM would be helpful to know.

Yes, fair point.

I have seen the problem with very few windows/tabs. Certainly as few as two windows, three tabs in total.

I should point out that it sometimes takes a few cycles of activating Terminal.app/quit/activate for it to show up.