6

Recently (possibly with the Sonoma update, but possibly even more recently than 14.0), 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

or, in the case of zsh,

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

Since originally posting this question (see updates below), it has become clear that the error appears to happen in multiple versions of macOS, on Intel and Apple Silicon. It does not appear to be due to installed software or config files.

I have traced this to an error coming from /etc/bashrc_Apple_Terminal (or /etc/zshrc_Αpple_Terminal) which is largely concerned with saving and restoring sessions for the various terminal tabs and windows. (Most of the following will specifically refer to the symptoms with bash but it’s similar for zsh.)

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 incorrectly contains the following text:

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

rather than echo Restored session: "$(/bin/date -r 1698759014) For some reason, the Saving session... text is appearing in the file (twice!) -- it is being sent to "$SHELL_SESSION_FILE" rather than stderr (via >&2).

I think I didn't make any changes to cause this, but perhaps I am wrong. The directory ~/bash_sessions/ seems to have recent files with this error, and slightly older files (as recent as yesterday!) which don't. I regularly update various packages with homebrew, and I have recently installed Python 3.12 from python.org, but I can't see how they could reach into the guts of shell startup.


Update: In fact, I see this even with a new user, and even if I use zsh rather than bash! (Apple Terminal has very similar code for session history management under zsh.) So it seems that some other recent change to my system is causing this. But I suspect it's not simply a Sonoma problem, since it does not appear to be widespread. Yikes!

Update 1a: Note that 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.)

Update 2: At least one other person is seeing this! Perhaps this indicates an issue with VS Code?

Update 3: After some back and forth in the comments below, it is clear that the error spans multiple versions of macOS on both Intel and Apple Silicon architectures, and we seem to have eliminated VS Code and possibly Python (we seem to be using different versions and installers) as the cause; I have removed /opt/homebrew and rebooted and still seeing the issue. Is it possible that any of these things somehow "pollutes" the environment -- e.g., /etc/ -- in some way that remains in place?

Update 4: Inspired by an interaction over on TidBits, I tried using Howard Oakley's excellent sandboxed lightweight VM, ViableS. I installed nothing, nada, zip, and added no files to ~/ or anywhere else. But 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

This seems to point, nearly conclusively, to a macOS bug. But I still don't understand how there are people reporting not seeing it.


Is anyone else seeing this? Is anyone explicitly not seeing it? Any ideas what's happening (or even debugging suggestions)?

I've asked a more specific version of this question over on Unix & Linux SA.

29
  • 1
    If you make a new user on the Mac, does it too emit that error? My hunch is your user profile has some startup file and not that the system is broken and this is a quick test to triage and narrow down where to look.
    – bmike
    Oct 31, 2023 at 14:00
  • 1
    I would worry about /usr/local/bin, there may be commands there which shadow the Apple ones and have different options.
    – nohillside
    Nov 3, 2023 at 14:37
  • 1
    I've got exactly the same problem with iMac, macOS version 12.7.1. And my MacBook with macOS 14.1 works fine (very similar setup otherwise). Nov 11, 2023 at 18:42
  • 1
    @AndrewJaffe iMac had VS Code 1.84.1, Macbook had VS Code 1.84.0. Upgraded Macbook to VS Code 1.84.2, rebooted, and now I'm also seeing the familiar error message there. Nov 12, 2023 at 20:41
  • 1
    I don’t have VSCode installed.
    – nohillside
    Nov 12, 2023 at 21:36

4 Answers 4

2
+50

Since I've been asked to do so in .zsh_sessions producing an error I post here the fact that commenting out the echo line did make the problem disappear in a similar case:

I commented out the echo -ne line in etc/zshrc_Apple_Terminal and the problem disappeared

  shell_session_save() {
    # Save the current state.
    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")
    

As per a user suggestion, so does replacing it by

print -u 2 $'\nSaving session ...' 
13
  • 1
    This solves the symptom, but it doesn't really give any insight into why the problem is occurring (which we still don't know!). And even with something like this solution (which I have also tried) I actually still get similar errors tracing back to the printf statement elsewhere in bashrc_Apple_Terminal. Nov 8, 2023 at 14:43
  • 2
    @AndrewJaffe Any answer helping users to avoid the problem til Apple fixes it is welcome.
    – nohillside
    Nov 8, 2023 at 14:51
  • 1
    @nohillside, Agreed, although what still isn't clear is whether this is (only) an Apple problem -- in which case maybe we can expect a fix from them -- or is it that those of us who are seeing it all have (e.g.) some common 3d-party software -- in which case we might be on our own! (I have actually filed a bug using Feedback Assistant) Nov 8, 2023 at 15:02
  • 1
    @AndrewJaffe The shell functions run for a specific user, so cross-user dependencies are unlikely. And if you only start one shell for a user, timing issues (which locking would solve) seem unlikely as well. Not sure we clarified the /usr/local/bin thing, is there anything in there which is also called from the session functions?
    – nohillside
    Nov 8, 2023 at 18:24
  • 1
    @Hugues, that directory (…Frameworks…/bin) is added to your path when you install Python from python.org, which explicitly changes your bash startup files — look in /Applications/Python\ 3.12 — whereas /usr/local/bin is probably homebrew Python. (Did you edit your startup files yourself in your attempts to fix this and ended up changing your path?) What’s interesting to me is that I recently switched from homebrew Python to the one downloaded from Python.org, and that is around when I started seeing these issues. So perhaps it is related? Nov 9, 2023 at 7:26
1

Since you have determined that your startup files are causing this (by testing a new user account without any customizations), I would take these next approaches.

  1. Run your modified files through a linter. Shell check is excellent in my experience: https://www.shellcheck.net/
  2. Set debug flag for bash early in your script.
  3. Closely look at any use of the variable you identified as getting stomped.

For item 2, perhaps you can set an alternate shell temporarily and then call bash:

/bin/bash -lixc exit 2>&1 | less

if your <GUID.session> file is unclean - we'll need to pick apart why your customizations are breaking that file generation in the function shell_session_save - on my system this is as follows:

me@mac ~ % which shell_session_save
shell_session_save () {
    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"
        )
        whence shell_session_save_user_state > /dev/null && shell_session_save_user_state "$SHELL_SESSION_FILE"
        local f
        for f in $shell_session_save_user_state_functions
        do
            $f "$SHELL_SESSION_FILE"
        done
        shell_session_history_allowed && shell_session_save_history
        echo 'completed.' >&2
    fi
}

What’s curious is zsh is also reported to have a curiously similar issue.

11
  • 1
    Well, I know exactly where the error occurs: it's in the line echo -ne '\nSaving session...' >&2, incorrectly writing to a file instead of stderr (although I think there are some rare occasions where other incorrect characters are being written to $SHELL_SESSION_FILE). And although the error seems to require (my?) startup files, I'm not completely sure that it's the files themselves that are causing the problems. Nov 1, 2023 at 22:46
  • Quite the mystery - I'm glad you know exactly where it occurs - it's hard for me to guess from here @AndrewJaffe but perhaps my thinking will help you over the gap between now and a fix.
    – bmike
    Nov 1, 2023 at 22:52
  • 1
    correct - I should have changed my shell to get that / got carried away with calling bash from zsh... @AndrewJaffe
    – bmike
    Nov 1, 2023 at 23:18
  • 1
    Got a similar issue, likely from the same shell_session_save line when using zsh. apple.stackexchange.com/questions/466160/…
    – Hugues
    Nov 8, 2023 at 0:20
  • 1
    Yes, I'm still on 12.7.1, as I did not want to upgrade for various reasons. It could however still be a MacOs X issue as there are regular updates for security reasons and there was one in October.
    – Hugues
    Nov 9, 2023 at 14:44
1

I saw this today! Haven't seen it before. I'm on Monterey (12.7.1 21G920).

I rebooted my MacBook today (not installing the update, just a normal reboot). After it restarted, I noticed that it didn't properly restore all my Terminal tabs, but instead restored the state from around Nov 2.

I think I quit the Terminal later again, and after I opened it again, I now saw this in every restored tab:

/Users/kuba/.zsh_sessions/C6E94843-05DC-43CC-933E-5190FC8E0825.session:2: command not found: Saving

I haven't seen that message before. I have a suspicion that it might have something to do with why the Terminal restored tabs state from Nov 2 instead of from before reboot… perhaps they've changed the way how sessions are stored in some recent update? (updated zsh to some new version?)

(More info: I don't have VS Code installed, I have Homebrew installed, but not many packages in it, and also MacPorts.)

1
  • thanks. Did you install anything or make any changes to your system since the previous reboot? Nov 27, 2023 at 10:04
1

I think I figured this out. Running multiple Terminal sessions at shutdown can cause a race condition in writing the history file. See my reply https://stackoverflow.com/questions/62316487/terminal-modified-permanently-by-vscode/77424721#77424721

But it doesn't have anything to do with VSCode; it's an Apple bug. Here's my fix:

scott@Mac-mini-x86 etc $ diff  bashrc_Apple_Terminal.orig bashrc_Apple_Terminal 
215,219c215,223
<       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
---
>       local save_lock_file="$SHELL_SESSION_DIR/_saving_lockfile"
>       if /usr/bin/shlock -f "${save_lock_file}" -p $$; then
>           (umask 077; echo 'echo Restored session: "$(/bin/date -r '$(/bin/date +%s)')"' >| "$SHELL_SESSION_FILE")
>           echo -ne '\nSaving session...' >&2
>           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
>           /bin/rm "${save_lock_file}"
>       fi

Note that it's pretty trivial; it just locks to serialize updating of the history file.

13
  • I can reproduce the problem with one Terminal session/one tab only.
    – nohillside
    Dec 11, 2023 at 5:07
  • Somewhat anecdotally, I am not seeing this with only one session. (But you might try deleting the files in ~/.bash_sessions or ~/.zsh_sessions first.) This interpretation makes some sense, but it is still weird that (a) it seems to have only started recently (but on multiple OS versions?); (b) the error is (almost) always the same, so the incorrect characters are always going in the same place. Dec 11, 2023 at 12:28
  • 1
    Also note that if your history file is messed up, it will continue to spew these errors until the process of starting and ending Terminal sessions truncates the messed up part of the history file. So the bug will show for a while even if you are just running a single Terminal session. :( Dec 16, 2023 at 17:11
  • 1
    Obviously the cause is two Terminal processes in a race condition to exit. I'm not sure exactly how I feel about the answer to symptom v cause -- it could be difficult to keep different system processes that might fire up a quick bash from terminating at the same time, and since this routine is the common point where the error occurs, I lean toward calling this a fix. Jan 5 at 22:18
  • 1
    As for it being a small, safe fix: simply locking the history file while writing to it is small (check out the patch), certain safe (multiple racers will just be serialized), but I suppose it could step on a few msecs of performance during startup/shutdown. I think the most pernicious part of the bug is that is corrupts the history file in such a way that the 💩 pile(s) it leaves there continue to cause errors for a while, making it appear as if the fix doesn't fix it. And then in the sort of behavior that gives Macs their reputation for being alive, it just .... goes away. Jan 5 at 22:22

You must log in to answer this question.

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