1

Every time I open a new Terminal window or tab, it shows this error before the shell prompt:

/etc/zshrc_Apple_Terminal:14: INSIDE_EMACS: parameter not set

(I don't use emacs, and I've noticed no other ill effects.)

As that indicates, my default shell is zsh. The error also appears when starting a new zsh instance from within any existing shell.

Line 14 of /etc/zshrc_Apple_Terminal is:

if [ -z "$INSIDE_EMACS" ]; then

So that file clearly expects $INSIDE_EMACS to be set, and gives the error when it's not. But I've not been able to find out what should be setting it (that's clearly not working on my machine). I have various user-level shell startup files, but none of those seem to be the cause, as that message appears before any of them have run.

There's an obvious workaround: edit that file (as root) and e.g. replace $INSIDE_EMACS with ${INSIDE_EMACS-} (which silently expands to empty string if the variable's not set). That works fine — but every time I upgrade macOS, that file gets replaced and the error is back! (This has happened with every upgrade since around macOS 12 Monterey; I'm now on the current macOS 15.5.)

I've not found this error online (other than my own mention in this answer), so I'm guessing it's not common, and probably triggered by some quirk of my own set-up. But I haven't found any possible cause.

What can I do to make this error go away for good? What should be setting $INSIDE_EMACS?

asked May 16 at 11:51
9
  • The error message doesn't make sense. if [ -z "$INSIDE_EMACS" ]; then doesn't throw an error if the variable is not set (as can be easily verified by running if [ -z "$INSIDE_EMACS" ]; then echo foo; else echo bar; fi), it just "expands" to an empty string which -z then tests for. Commented May 16 at 12:08
  • Could you replace INSIDE_EMACS by something else (e.g WTF_IS_GOING_ON_HERE) and launch a new zsh tab to see whether the problem occurs as well (with the new variable) or is tied to INSIDE_EMACS? Commented May 16 at 12:12
  • @nohillside Your example does give an error on my machine (for any unset variable, not just INSIDE_EMACS). Further investigation suggests that's due to the shell option setopt nounset (AKA set -u) being set. So that looks like the problem, rather than INSIDE_EMACS not being set. Now, it's entirely possible I set that option somewhere (I have set -u in most of my shell scripts, as it protects against typos and makes good sense to me) — but I can't find it anywhere! (Except for /etc/rc.common — but I commented it out there, and still get the error, so that's probably not it.) Commented May 16 at 15:54
  • 1
    zshenv is meant to set env variables only, not shell options, aliases or similar. Just set the option in .zshrc instead, this will be read after /etc/zshrc Commented May 16 at 18:44
  • 1
    social.jvns.ca/@b0rk/114512574868564749 may help. The files in /etc are read immediately before the corresponding dot version. Commented May 16 at 21:59

1 Answer 1

2

This command shows all files sourced by zsh at invocation:

zsh -o SOURCE_TRACE

The OP reports that in his .zshenv file, which is sourced before /etc/zshrc_Apple_Terminal, he had set the shell option no_unset. This option causes an error to print when an unset parameter is expanded.

From the zshoptions(1) man page:

UNSET (+u, ksh: +u) <K> <S> <Z>
 Treat unset parameters as if they were empty when substituting,
 and as if they were zero when reading their values in arithmetic
 expansion and arithmetic commands. Otherwise they are treated
 as an error.
answered May 16 at 16:18
1
  • To summarise comments: the underlying problem is that I had shell options in ~/.zshenv (which runs before /etc/zshrc_Apple_Terminal); they should instead be in ~/.zshrc (which runs after), which avoids the error. Commented May 17 at 9:04

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.