('xyz' can be as far as I know, anything that is on my first line of .zshrc. Even an empty line as a first line of .zshrc returns the same output upon opening a terminal but ending with whitespace. I also tried pwd thinking of all instances of terminal input that could be found somewhere and what I assume is one of the most universal commands, but it too can not be found.)

I'm certain the issue has arisen strictly from changes in my .zshrc file because the problem occurred after hours of tweaking it/closing & opening terminals to test fixes to a previous issue involving aliases conflicting between .zshrc and oh-my-zsh (Namely, I was unaware oh-my-zsh added a line to source somefile that somehow takes precedence over my custom aliases on .zshrc. See link: Why doesn't 'sourcing' my .zshrc file change my aliases?).

Potentially relevent/generally helpful info:

-Problem occurs in both gnome-terminal(preferred and used almost exclusively) and urxvt(backup). -Other than this consistent 1st hiccup, everything else works perfectly fine. Even all my aliases and oh-my-zsh schemes function properly.

--fortune -o was my initial first line before I began experimenting to find solutions. (it also returned command not found: fortune)

--A big indicator of what I potentially messed up probably involves oh-my-zsh in someway because my last attempt to fix the problem mentioned in the link above, was to add

source $home/.zshrc

directly below the line containing source $ZSH/oh-my-zsh.sh

The idea behind this was my thinking that sourceing my custom .zshrc file would cause the aliases within that file to take precedence over whatever aliases are being determined by the oh-my-zsh file which I don't much know about/understand/how it got there to begin with. After saving the file, closing the terminal and opening a new one up to test the alias changes, a very confusing bug occured. The terminal opened up normally and the color scheme and everything else about it aesthetically was accurate, but it was looping random fortunes at a fairly rapid pace in an unending loop. No common keybindings worked to stop it(Ctrl+C, Ctrl+D, Esc, Enter, 'Q'). So I had to close it with a gnome keybinding. The error persisted on urxvt in the exact same manner. Removing the source $home/.zshrc line solved my looping fortune issue but caused my current conundrum

  • I'm wondering if you can get closer to finding out what's wrong by starting zsh with -v (i.e. open any terminal with any shell, and in there start zsh -v). This should tell you what gets executed and what scripts get sourced from other scripts (will probably be very much output). I'm wondering if your zshrc gets sourced a second time, on top of the regular call by zsh).
    – pseyfert
    Commented Jan 31, 2019 at 11:32
  • Its a pretty excessive amount of output that I can't make much sense of. Should I throw it in a pastebin or something?
    – Grant
    Commented Jan 31, 2019 at 11:42
  • the "big indicator" is probably a red herring. by calling source $HOME/.zshrc from within .zshrc you just created an infinite loop of a script calling itself.
    – pseyfert
    Commented Jan 31, 2019 at 11:47
  • hm, i was afraid the output could be too big to handle. and someone other than you might even have more problem as they're unfamiliar with what you have in your scripts (which you could recognize). Can you try going towards a minimum working example? i.e. remove things from your .zshrc (make a backup before, or even put it in version control to go through your steps) until the error disappears? I suspect once you exclude oh-my-zsh.sh the -v output might even become readable, and we'll know if the problem is on your side / on the oh-my-zsh side / a combination of both.
    – pseyfert
    Commented Jan 31, 2019 at 11:49
  • 1
    "every command possible followed by my usual .zshrc file" okay, so what is the last thing before your zshrc? since apparently the beginning of your zshrc is command-not-found'ed something that happens before tries to run it (or expects a command). looking at this post, could there be something buggy in your .zprofile or .zshenv (or worse, in /etc/zsh*)
    – pseyfert
    Commented Jan 31, 2019 at 16:47

1 Answer 1


The entirety of this issue hinged on 2 complications. The first was my bonehead mistake of thinking I could have a script source itself. Perhaps this is possible in other contexts, but in my specific case it caused an infinite loop of my .zshrc calling itself. The second complication arose from a poor attempt to resolve the first issue: using libreoffice to edit a system configuration file. My infinte script call made all terminals unusable and with no other gui text editors available, I thought libreoffice would be fine for a single line change edit. When saving any textfile, it appears that libreoffice, as of this date, will prepend textfiles with a Byte Order Mark(https://en.wikipedia.org/wiki/Byte_order_mark). I don't know much about them at all, but I can say for certain that the default vim editor will not display them in any noticeable way without vim commands.

You can remove the aforementioned BOMs in vim, though. :set bomb? will output bomb if the current file does indeed have a BOM. Conversely, nobomb will be returned if none are present.

And intuitively enough, you can have vim remove this with :set nobomb

Do remember to save the file afterward, though. Otherwise, no change will occur.

You must log in to answer this question.

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