mjhjmtu

('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

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.