Actually, poking at this some I believe this is correct behavior based on platform differences between cmd.exe and bash (and other Unix shells).
On a Unix system, create a file containing "ls" with no newline. For example, WriteString["test_file","ls"]. Now execute bash < test_file. You'll see the contents of the current directory (or technically, whatever directory bash is in after processing your non-login init files).
On Windows, create a file containing "dir" with no new line by replacing "ls" with "dir" in the above command. Now execute cmd.exe < test_file. You'll see the output More? in your shell, just as in the output given in the question above.
So basically, bash considers an end-of-file with no newline to be valid input, but cmd.exe does not. Which is surely one reason why all the examples in the documentation end with newlines. I'm therefore inclined to consider the current behavior correct and desirable--if the program being called operated at a byte level, we surely wouldn't want to throw an extra 10 byte (or 10 13 bytes on Windows) at it.
datewas a builtin command and OP tried to run it as an executable. Herediris also a builtin, but OP is sending it tocmd.exevia stdin. In fact it does work if we also send a newline afterdir. Do you know why this newline is not required on Unix? After all, typinglsmanually and not pressing Enter does nothing ... I always assumed thatRunProcessadds that Enter automatically, and I am surprised that it does not also do so on Windows. – Szabolcs Sep 07 '17 at 08:19