@EliahKagan looks like you posted your answer :)

Yes, I did. I didn't try to explain the shell syntax errors, though. I just included enough to make the point about how if one sees one's C++ source code in errors shown when one tries to run what one thinks is one's compiled program, then one is probably doing it wrong. I still hope you, or someone, posts another answer about those errors.

ok, I will have a go at doing that then if you think it would be useful

I had said it doesn't require any C++ knowledge, but it occurs to me that this might not be 100% so in the absence of the source code that caused the problem. When I saw this question, I immediately knew the cause of the errors (though not quite how the OP got to that point) because I've seen it before.

I know // comes before a comment (like # in Bash)

the shell thinks that word starting with // is a path, so it says no such file or directory, etc...

@Zanna Right, and # in C++ introduces a preprocessor directive, like #include <iostream>, so those don't produce syntax errors if run as shell code because they're comments to bash.

@EliahKagan so it doesn't do anything with them at all :)

@Zanna Bash and other shells don't, right. They're not comments in C++, but they are in a shell script.

Also, it's common, especially in C++ where using () as a parenthesized list of formal parameters means the same thing as (void) in C, to write int main(). This is almost universal in introductory C++ exercises and extremely common in real world code too.

ek@Io:~$ bash <<<'int main()'
bash: line 1: syntax error near unexpected token `('
bash: line 1: `int main()'

@EliahKagan Note that one gets the same message if one writes non-empty parameter lists, so just about any header line for a function in C or C++ will produce an unexpected token error about an opening parenthesis when bash processes it as a shell script (one gets similar errors in other shells of course, but they may not be worded the same, because different Bourne-style shells word their equivalent errors differently much of the time).

Bash might think something() is going to be a function definition

Yeah, that's a good point. That could happen in C code, because in C89 (and also in pre-standard C) there is implicit int, so you don't have to declare the return types of your functions.

ek@Io:~$ gcc -x c - <<<'main(){}'
<stdin>:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]

In all standard dialects of C++ (as well as in C99 and later for C), implicit int is prohibited and function declarations (including those that begin definitions) must explicitly state their return type. But some C++ compilers accept code with implicit int anyway, and some people write it, so it could happen when someone is trying to program in C++ too.

Weirdly, when I have g++ compile that same code as C++, it doesn't warn by default!

ek@Io:~$ g++ -x c++ - <<<'main(){}'
ek@Io:~$ g++ -Wall -x c++ - <<<'main(){}'
<stdin>:1:6: warning: ISO C++ forbids declaration of ‘main’ with no type [-Wreturn-type]

Ideally we would have a separate question that shows actual source code and asks about that message. But in practice we're unlikely to get that, because once a novice has identified those errors as an interesting aspect of their problem, they're very close to a solution. A self-answered question could be posted, which is often an excellent thing to do, but it seems sort of excessive when we have a question right now that centers on the matter and shows the error messages.

still, you have to enter something reasonably syntactically valid to avoid getting a fairly informative error...

$ bash <<< 'main()'
bash: line 2: syntax error: unexpected end of file
$ bash <<< 'main(){}'
bash: line 1: syntax error near unexpected token `{}'
bash: line 1: `main(){}'
$ bash <<< 'main(){ unicorns ; }'
$

Oh, valid in the syntax of the shell.

yeah, that's what I mean

Yes. However, the {} case is contrived. Bash gives an error there because {} is not read as a { followed by a separate }, because those characters are shell keywords rather than shell metacharacters -- they do not cause text to be read as separate tokens.

Also, in the case of an empty { } when the tokens are separated, the shell will give a different error:

ek@Io:~$ bash <<<'main() { }'
bash: line 1: syntax error near unexpected token `}'
bash: line 1: `main() { }'

Because empty groupings with { and } in a Bourne-style shell are not allowed; your group has to have at least one command in it. This doesn't give an error, though:

bash <<<'main() { return 0; }'

main() { return 0; } is a C89/bash polyglot that does... nothing. (If run as a shell script. If it's sourced you get a main shell function defined that does nothing, and defining a noop function is not itself a noop.)

I'm just thinking about the extent to which you could write some valid C++ code and throw it into the shell without getting any informative errors. You suggested it might be possible to write something like main(){} when trying to write C++, so I am seeing what would happen when Bash tries to execute the source file with such lines as a script

Yes. Makes sense.

anyway, they got an error for line 1, which was a comment, because Bash thought the C style comment was a path, then they got no error for line 2 or 3 which probably had #include something, because Bash thought whatever followed # was just for humans and none of its business. Then they got an error for line 4 because ( couldn't be doing anything valid after two random words... But why didn't they get any more errors after that? Presumably they had something more

@Zanna Or one or both of lines 2 and 3 could've just been blank lines.

yeah, and #include whatever came after...

Btw the phrase "C style comment" is usually used used to mean the kind that starts with /*, can span multiple lines, and ends with */, since C has always had that style but only got the single-line // style in C99. // comments have always been in C++ and some people call them "C++style comments" but I would usually just call them single-line comments.

ok :)

@Zanna Does bash continue parsing a script once it sees its first actual syntax error?

ek@Io:~$ bash <<<$'()\n()\n()\n()\n()'
bash: line 1: syntax error near unexpected token `)'
bash: line 1: `()'

I guess /* could have caused untold havoc when the shell tried to run the script :)

Haha indeed. It might be good to mention that, as it's a popular style for comments that span multiple lines.

@EliahKagan oh haha no, it's clear

various distractions happening O.o might take me some time to write this answer...

I attempted to answer that question