Nothing weird there, just the command substitution working.
When you tested the command
$(grep -R -I --exclude-dir=addons "^[^#]*print(" )
the shell first performed the command substitution on the command line before actually attempting to execute the command line after transforming it with the command substition.
From your bash -o xtrace ... output, I can see that executing the command within the parenthesis results in output:
Map/Places/place.gd: print("enter")
In other words, grep found an uncommented print( string in a file named Map/Places/place.gd, as part of a line containing print("enter").
Then, grep's output output is inserted in place of the $( ... ) command substitution expression in the original command line. Because the entire command line is enclosed in $( ... ), the entire command line is replaced with the output above.
Then, the shell attempts to execute the transformed command line. Because there was nothing but the command substitution expression in the original command line, the shell ends up attempting to execute the output of the command that was within the command substitution expression as the actual command.
In other words, it will attempt to find an executable with a current-directory-relative pathname of Map/Places/place.gd: and give it print("enter") as the first argument.
You probably don't have any file named place.gd: (with the colon included in the filename). Because that does not exist, the shell displays an error message. Effectively, it says:
"I'm bash, and I have a problem with the Map/Places/Place.gd: you just told me to execute: There is No such file or directory."
It just displays this in a slightly more terse form:
bash: Map/Places/place.gd:: No such file or directory
In your script, look at these two lines:
RESUlT=$(grep -R -I --exclude-dir=addons "^[^#]*print(" )
echo "${RESULT}"
The output of the command within the $( ... ) command substitution expression is stored in the shell variable RESUlT. Then, in the next line, you are telling the shell to output the contents of a different variable RESULT. Yes, they are different: note the lower-case l in the first variable name.
The "one weird thing in the Terminal" is just the same as the error in your first terminal test.
The first command line
whereis grep
returns the output:
grep: /usr/bin/grep /usr/share/man/man1/grep.1.gz /usr/share/info/grep.info.gz
The second command line
$(whereis /usr/bin/grep)
will first run the same command as the first command line, capture its output, replace the command substitution expression with the output, and then attempt to execute the resulting command line.
Since the command line has now been transformed to
grep: /usr/bin/grep [...etc...]
the shell now attempts to find the command grep: (with the colon). Since there are no slashes in the "command", the directories listed in $PATH are searched, and then apparently then a helper function from the optional command-not-found package kicks in.
It produces a more verbose error message with some suggestions, identifying that grep: might have been grep with a mistyped colon appended, and if that's not the command you're looking for, you might need to install a package that contains the command you want. But in this case, those suggestions are not applicable, because you effectively tried to blindly execute the output of another command.
bash -o xtrace path/to/the/scriptto see what is actually done.-R -I --exclude-dirare standardgrepoptions. Make sure your script calls thegrepimplementation that supports those extensions.=inRESULT=$(...