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.
date
was a builtin command and OP tried to run it as an executable. Heredir
is also a builtin, but OP is sending it tocmd.exe
via 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, typingls
manually and not pressing Enter does nothing ... I always assumed thatRunProcess
adds that Enter automatically, and I am surprised that it does not also do so on Windows. $\endgroup$ – Szabolcs Sep 7 '17 at 8:19