Hey, thanks for the input!
My shell-file-name is indeed pointing to cmdproxy.exe, and after changing shell-command-switch to "/k" or "-k", I get a similar output:
#+begin_src shell
echo 1
echo 2
echo 3
#+end_src
#+RESULTS:
| Microsoft | Windows | [Version | 10.0.14393] | | | |
| (c) | 2016 | Microsoft | Corporation. | All | rights | reserved. |
| | | | | | | |
| c:\tmp>echo | 1 | | | | | |
| 1 | | | | | | |
| | | | | | | |
| c:\tmp>echo | 2 | | | | | |
| 2 | | | | | | |
| | | | | | | |
| c:\tmp>More? | | | | | | |
echo 1
echo 2
echo 3
#+end_src
#+RESULTS:
| Microsoft | Windows | [Version | 10.0.14393] | | | |
| (c) | 2016 | Microsoft | Corporation. | All | rights | reserved. |
| | | | | | | |
| c:\tmp>echo | 1 | | | | | |
| 1 | | | | | | |
| | | | | | | |
| c:\tmp>echo | 2 | | | | | |
| 2 | | | | | | |
| | | | | | | |
| c:\tmp>More? | | | | | | |
Where only the last line is missing.
Another observation that might be relevant, is that the block execution works well when I set shell-file-name to "powershell.exe"
#+begin_src shell
echo 1
echo 2
echo 3
#+end_src
#+RESULTS:
| Windows | PowerShell | | | | | | |
| Copyright | (C) | 2016 | Microsoft | Corporation. | All | rights | reserved. |
| | | | | | | | |
| PS | C:\tmp> | echo | 1 | | | | |
| 1 | | | | | | | |
| PS | C:\tmp> | echo | 2 | | | | |
| 2 | | | | | | | |
| PS | C:\tmp> | echo | 33 | | | | |
| PS | C:\tmp> | | | | | | |
echo 1
echo 2
echo 3
#+end_src
#+RESULTS:
| Windows | PowerShell | | | | | | |
| Copyright | (C) | 2016 | Microsoft | Corporation. | All | rights | reserved. |
| | | | | | | | |
| PS | C:\tmp> | echo | 1 | | | | |
| 1 | | | | | | | |
| PS | C:\tmp> | echo | 2 | | | | |
| 2 | | | | | | | |
| PS | C:\tmp> | echo | 33 | | | | |
| PS | C:\tmp> | | | | | | |
And here, it might be that the missing newline in the last command is visible, hence the double '3' character (one is a part of the "echo 3" input, the second is the output "3" echoed back).
You also mentioned the source code block is being passed through the "-c" flag as a command-line argument.
I might be misunderstanding something here, but it seems like it is being passed through the stdin of the shell process when the calls process-file -> call-process are being made.
Just to confirm, I've made a simple utility that prints the contents of argc and argv as hex strings, and got the following output when setting it in place of the the shell-file-name:
#+begin_src shell
echo 1
echo 2
echo 3
#+end_src
#+RESULTS:
| argc: | 3 |
| 633a5c6d73797336345c686f6d655c4f736865725c6563686f5f6865782e657865 | |
| 2d63 | |
| 633a2f6d73797336342f686f6d652f4f736865722f6563686f5f6865782e657865 | |
echo 1
echo 2
echo 3
#+end_src
#+RESULTS:
| argc: | 3 |
| 633a5c6d73797336345c686f6d655c4f736865725c6563686f5f6865782e657865 | |
| 2d63 | |
| 633a2f6d73797336342f686f6d652f4f736865722f6563686f5f6865782e657865 | |
Which translates to:
c:\msys64\home\Osher\echo_hex.exe -c c:/msys64/home/Osher/echo_hex.exe
Exposing that there are two nested shell-file-name running.
And now I was curious to see if babel executes cmdproxy.exe -c cmdproxy.exe, so I fired up Procmon, and indeed that was the case (see attached screenshot).