I'm now back at my computer (was using a tablet for the post above) and I tried compiling your sketch.
At first, I only got one error: "fatal error: process.h: No such file or directory" and pointing at the first line where process.h is being included. I changed "process" to "Process" and it compiles past that point. Very curious: I'm on Windows and I thought file names were not case sensitive? But here, it seems to make a difference (looking at the examples, they all seem to use Process with a capital "P" when including the file.)
Fixing that, and recompiling, there are more errors:
- Line 19: missing terminating " character - You have a string that starts with a double quote character (the second quote in the string is escaped with a backslash, putting the double quote character in the string) but at the end, you just have two double quote characters with no escaping backslash. The first double quote ends the string. The next double quote starts a new string with the characters ");" in it (adjacent constant strings are automatically concatenated) but then you have the end of the line, so the compiler complains about the missing double quote to terminate that second string. You could fix the error by adding another quote at the end of the string, and that would make the compiler happy, but that would not fix your problem, as you would not have a double quote as part of the devid string. You need to add a backslash between the 5 in the devid string, and the double quote that you want to be part of the string. That will include that quote character in the string itself. The next quote that follows it will then properly terminate the string instead of trying to create a new one.
- Line 20: expected ')' before 'p' - This is an example of an error being caused by a previous error. In the line above, the compiler took the closing parenthesis and semicolon as part of the unterminated character string, so it doesn't realize you were intending to end that statement. Therefore, it reads the next statement as a continuation of the previous statement, but it doesn't make sense. So it complains that it thinks there should be a closing parenthesis there. Of course, nothing is missing there, and nothing needs to be fixed on that line. That line will compile properly when the line above it is fixed.
- Line 25: 'c' was not declared in this scope - It's complaining that the variable c is not declared in the Serial.print(c) statement. But it is declared in the line immediately above. So why is this a problem? The line above the declaration is a while statement. That will execute the next single statement as long as the condition is true. That next statement is a new declaration scope. The statement in that scope after the while statement is the definition of the variable c, and a statement to read from the process. The scope of that variable is only that one statement associated with the while loop. The next statement (the print) is not part of the while loop, and the scope goes back to the scope that existed before the while statement, and that scope does not include the variable c. That triggers the error. The real problem is that you want to have two statements that are part of the while loop, and the solution is to use curly braces after the while statement to start a new block. Everything that is inside the opening and closing braces is treated as a single statement by the while loop. The definition of c at the beginning of that block of statements (in this case it would be two statements) remains valid until the end of the block (the closing curly brace) so the print statement will then compile.
This last error is a common one. This is the code in question:
while (p.available()>0)
char c = p.read();
Serial.print(c);
Serial.flush();
You have it indented where it appears that you want both the read() and print() statements to be part of the while loop. That would make sense. In some languages, like Python, doing that indenting is enough to make the indented statements part of the while loop. But C++ (which is what the Arduino is using) totally ignores indenting - doing the indenting is just to make it more readable for you. This is a very common error. As far as the compiler is concerned, what it's really doing is this: (using the Auto Format command from the Tools menu will reformat it to look like this, making the problem more obvious)
while (p.available()>0)
char c = p.read();
Serial.print(c);
Serial.flush();
Here, it's clear that only the read() statement is in the loop. It will read all characters, and essentially throw them away. You reach the print() statement only when the loop finishes, and at that point the variable c (as well as all of the characters that have been read) are gone and no longer accessible. The fix is to add the curly braces:
while (p.available()>0)
{
char c = p.read();
Serial.print(c);
}
Serial.flush();
This code will work as you expect. The variable declaration, and the read() and print() calls are all inside of the while loop, and it will repeatedly read and print character as long as they are available.
Another common error is to add a semicolon when one isn't needed. Many people automatically add a semicolon at the end of each line, thinking it is a line terminator. In reality, the semicolon is a statement separator. Consider this code, which is the same as the code above with the addition of a semicolon after the while statement:
while (p.available()>0);
{
char c = p.read();
Serial.print(c);
}
Serial.flush();
In this case, that added semicolon causes lots of problems. It is actually putting an empty NULL statement after the while statement, separating that NULL statement from the block of statements in the curly braces. What this is doing is telling the while statement to do nothing as long as characters are available. Once characters are no longer available, it will enter the block of statements denoted by the curly braces. It will create a variable c, read a single character into it, print the character, and then end the block. That will destroy the variable c, making it no longer accessible. That block will only be executed once, because it is no longer associated with the while statement - that semicolon has told the while statement to do nothing. In this case, the problems isn't really that the block statement will only be executed once. In reality, it will never be executed: since nothing is done inside the while statement to consume characters from p, the loop will never end. That infinite loop will run forever, and the sketch will never get past that line.
So that gives an example of type of things you need to look for when trying to get a sketch to compile. It's the details that count - every little character could be important. When you see an error message, you've got to look at the smallest of details to see what might be wrong. In the discussion above, I show three errors: a missing backslash which needs to be added, an error on the next line that isn't really an error and which will be fixed by fixing the first error, and some missing curly braces to make the loop do what you want it to do. Fix those errors, and then try to verify the sketch again. You could very well end up with a new set of errors. This can be an iterative process where you have to go through several cycles of fixing errors and verifying again.
Once you have the sketch successfully verified, then the hard work begins: debugging the code and getting it to do what you want it to do!