[anyfoo]

Does the shell filter the carriage return out in the error for some reason? I would more expect something like:

  /bin/bash
           : No such file or directory

(Not that that's more helpful to a user, but at least a trained eye would immediately get very suspicious.)

[kymaz]

I guess it depends greatly on what version of bash and such, but with something recent, trying to execute the script will escape the problem characters when printing if it prints the interpreter name at all, and possibly also say 'bad interpreter: no such file or directory"

...since there's more than 2 valid line ending configurations?

[anyfoo]

Yeah that sounds well plausible, especially because there seem to be many (minor and major) versions of bash still around in different contexts. Not to speak of any other shell. Escaping seems best!

The "bad interpreter" being there or not might be OS-specific, though. Unless some bash versions use fork+execve vs. posix_spawn or similar and that makes a difference there. I haven't checked. Overall I can see how even some current stuff might give the confusing message...

[Thespian2]

That would be a "line feed" (0x0A) - Carriage return is (0x0D) (ascii values 10 and 13, respectively) the Mac/Windows conversion is the difference between CR and CR/LF

All I can guess is that in terminal, when that particular version of bash and OS interacted, it didn't go back to the start of line, and the CR was unprintable, so it all ended up on the same line.

I'd expect to have seen something like what you describe with the line break, if it were a bare LF, but in my case, it wasa bare CR.

[anyfoo]

Sorry, yes, I did mix up CR and LF in my example output that I would expect. So then I would actually expect:

   : No such file or directory

(And the rest still applies.)