/etc/zshrc_Apple_Terminal

[Richard Mitchell]

This is NOT an iTerm2 issue but others here may have ideas/solutions.

I recently started getting ~this error when opening a new session:

.zsh_sessions/w1t0p0:A5542445-E614-4CDE-A240-B7F8788ED896.session:2: command not found: Saving

After a lot of searching, discovered it is coming from:

===> /etc/zshrc_Apple_Terminal : 252 lines <===

214    # Save the current state.

215    if [ -n "$SHELL_SESSION_FILE" ]; then

216        echo -ne '\nSaving session...' >&2

217        (umask 077; echo 'echo Restored session: "$(/bin/date -r '$(/bin/date +%s)')"' >| "$SHELL_SESSION_FILE")

I'm manually sourcing this file in my .zshrc because it does seem interesting stuff.

This error is new and apparently the file was updated recently:

       9,335 2023-10-12 07:10:05   zshrc_Apple_Terminal

Ultimately the above code writes into $SHELL_SESSION_FILE (~/.zsh_sessions/$TERM_SESSION_ID) the following line:

cat ~/.zsh_sessions/w2t2p0:362905B6-935A-4567-908C-8885E363590E.session                           

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

The "Saving session..." should have gone to stderr, but is going into $TERM_SESSION_ID instead.  Elsewhere, Apple runs the output file, which generates my initial error message:

===> /etc/zshrc_Apple_Terminal : 252 lines <===

107     # Restore previous session state.

108     #

109

110     if [ -r "$SHELL_SESSION_FILE" ]; then

111    . "$SHELL_SESSION_FILE"

112    /bin/rm "$SHELL_SESSION_FILE"

113     fi

Does anyone understand what is going on?  I can't imagine what I could be doing that is redirection stderr and I don't see where Apple's script is doing that either.

As anyone else seen this?

Thanks

[Richard Mitchell]

A logical explanation is that stderr gets closed and the new log file gets opened, re-using fd 2 (previously closed) for the log file.  Now the output to fd 2 and the log file are the same, putting the output intended for stderr into the log file.  However, I can't find where this is being done

[Adrian Bool]

If you remove the call to /etc/zshrc_Apple_Terminal from your ~/.zshrc and:

sudo cp /etc/zshrc_Apple_Terminal /etc/zshrc_iTerm.app

Do you still get the error?

aid

-- 
You received this message because you are subscribed to the Google Groups "iterm2-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iterm2-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/iterm2-discuss/122b7550-9d29-45b5-95c3-8a3ed1dd450an%40googlegroups.com.

[Richard Mitchell]

I haven't tried that - what do you think is happening?

In .zshrc, I have moved the 'source /etc/zshrc_Apple_Terminal' to above 'source "${XDG_CACHE_HOME:-$HOME/.cache}/p10k-instant-prompt-${(%):-%n}.zsh".

Preliminary testing gives hope, but it hasn't been in effect long enough to be beyond wishful thinking, but it also doesn't appear to caused an adverse effects.

[Richard Mitchell]

To be clear, I haven't found anything in the cache file (but it is long) that would cause this issue,  just moving the Apple file before anything of consequence was done in .zshrc.

[Adrian Bool]

Like you, I don't really know, but it seems to make sense to ensure that Apple's script is called "as it was meant to" from the last few lines of /etc/zshrc (when running in iTerm) as opposed to from your ~/.zshrc in which something within the environment may have changed...

Zero guarantee of resolution of issue! ;-)

Interesting question though: if you open Apple's Terminal app, do you see the same issue?

Cheers

aid

To view this discussion on the web visit https://groups.google.com/d/msgid/iterm2-discuss/2ebac0f8-9b2e-423a-b231-eea1ef908b6en%40googlegroups.com.

[Richard Mitchell]

I looked thru the Apple script and didn't find anything using $0, unlikely the name makes any difference.

The other question would be is if the Apple script does anything that is specific to Terminal and not supported by iTerm2, but that doesn't seem to be the case either (the inverse is not true).

I don't currently see the issue when opening Terminal, but haven't seen it either in iTerm2 after moving the source line up, before p10k loads its cache for instant-prompt,

The p10k cache file does have this line:

258   exec 2>&1 {fd_null}>&-

along with other lines with the &- syntax.  Section 7.1 of https://zsh.sourceforge.io/Doc/Release/Redirection.html

states:

The syntax {varid}>&-, for example {myfd}>&-, may be used to close a file descriptor opened in this fashion. Note that the parameter given by varid must previously be set to a file descriptor in this case.

Given I had already suspected stderr was getting closed (but I'm too lazy to fully understand what and when p10k is closing FDs) this is most likely the culprit.

[Richard Mitchell]

Looking again at the Apple code, my explanation does not make sense.  oh well.