RunProcess doesn't list files on Windows

I am using Windows 10, Mathematica version 11.0.1.

SetDirectory["C:\\"];
RunProcess[$SystemShell, All, "dir"] I found that SystemShell doesn't work on my computer, the above gives <|"ExitCode" -> 0, "StandardOutput" -> "Microsoft Windows [\[Degree]æ\[PlusMinus]¾ 10.0.15063] (c) 2017 Microsoft Corporation¡£\[PlusMinus]£ÁôËùÓÐÈ¨Àû¡£ C:\\>More? ", "StandardError" -> ""|> What is wrong? How to fix this? • Possible duplicate of RunProcess seemingly does not work on my Windows system – Itai Seggev Sep 7 '17 at 7:07 • @ItaiSeggev I don't think it is a duplicate. There, date was a builtin command and OP tried to run it as an executable. Here dir is also a builtin, but OP is sending it to cmd.exe via stdin. In fact it does work if we also send a newline after dir. Do you know why this newline is not required on Unix? After all, typing ls manually and not pressing Enter does nothing ... I always assumed that RunProcess adds that Enter automatically, and I am surprised that it does not also do so on Windows. – Szabolcs Sep 7 '17 at 8:19 • I see. I didn't read this carefully enough. This does seem curious. Do we have any idea if this is new in 11 or has always been the case, and if this is specific to Windows 10 or affects all versions? But I'll also ask the relevant developer to opine. – Itai Seggev Sep 8 '17 at 4:36 2 Answers It will work if you send a newline at the end of dir: RunProcess[$SystemShell, All, "dir\n"] (* note the \n *)

What I do not understand is why this newline is not necessary when running the equivalent command on Unix-like systems. On OS X, the following works:

RunProcess[$SystemShell, All, "ls"] (* no \n needed *) Update: As pointed out by Itai, the difference in behaviour between Windows and Unix is normal. • Thank you so much. Szabolcs. This works. But weird enough : ) – matheorem Sep 7 '17 at 8:29 • Anyway, I thought using$SystemShell may solve my problem mathematica.stackexchange.com/q/155185/4742 . However, I just tried, it didn't work either. – matheorem Sep 7 '17 at 8:30

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.

• Thank you. interesting observation. +1 – matheorem Sep 8 '17 at 8:31