Thanks for the suggestions!
1. Another naive work around attempt. Again, I'm going from memory, documentation, and what I have previously written.
I have in my init a command to open a terminal when working on Windows that looks like:
(start-process "cmd" nil "cmd.exe" "/C" "start" "cmd.exe" "/K" "cd" dir)
This starts a cmd process with /c which terminates the prompt after the command that follows is run. The command That follows starts another cmd process with /k which changes the directory and leaves the terminal open.
I have another command to open QGIS that does the same thing:
(start-process "cmd" nil "cmd.exe" "/C" "start" "\"qgis\"" "cmd.exe" "/K" "C:\\Program Files\\QGIS 3.22.3\\bin\\qgis.bat")
It's not clear to me why the extra call to a second cmd with /k is needed. Maybe it's copy-pasta or Windows being Windows.
Anyway, I mention these because I wonder if we might be able to do something similar.
Try changing `shell-file-name' to "cmd.exe" (ideally, the full path) and `shell-command-switch' to "/k" (or maybe "-k"). My hope would be that the final call would look something like,
cmd.exe /k cmd.exe /k <executes-input-file-as-stdin-or-whatever>
Given my analysis, I'm not sure if there's a way we could trick the call into being `cmd.exe /c cmd.exe /k input-file'.
If running cmdproxy.exe /c cmdproxy.exe /path/to/input is not wrong, the
problem is on Emacs side.
Osher, could you try putting your example script into a file and running
the command line directly? What will it output?
Unfortunately, it seems like cmdproxy.exe and cmd.exe cannot accept an input file as a command-line argument and execute it.
In the case of running :
cmdproxy.exe /c cmdproxy.exe /c C:/tmp/inp
We get:
cmdproxy.exe /c cmdproxy.exe /c C:/tmp/inp
'C:/tmp/inp' is not recognized as an internal or external command,
operable program or batch file.
If we're insistent on passing the input through the command line arguments, I can think of two ways to go about this, but both seem undesirable:
- Dumping the content of the input buffer into a ".bat" file and then passing it as an argument. That way we end up executing "cmdproxy.exe /c cmdproxy.exe input.bat", but then batch files produce a slightly different behaviour than running in the context of an interactive shell.
or
- Concating the lines together with the "&" in between them. This would look like 'cmdproxy.exe /c cmdproxy.exe /c "echo 1 & echo 2 & echo 3", which is also a pretty nasty solution in my opinion.
This leads me to your next point, which sounds like the most natural way to go about it.
2. We could write some ob-shell code to explicitly handle Windows cmd and powershell. For example, call `process-file' similar to the stdin/cmdline branch of `org-babel-sh-evaluate'.
I'm open to this, but, like I've said, I don't have a Windows machine to work on right now. I'd not be able to verify it. I, and I'm sure others, would be happy to guide you if that's something you'd like to help implement.
I think it could be enough to make sure the input ends with a newline, in which case it could be done the way I proposed in the first message, that is changing:
(t (org-babel-eval shell-file-name (org-trim body))))))
to
(t (org-babel-eval shell-file-name (concat (org-trim body) "\n"))))))
I think as long as this change doesn't break the code in non-Windows operating systems (How would we go about verifying this?), it would be preferable due to its simplicity and minimality.
If for any other reason you would rather not change the org-babel-sh-evaluate, and would like to implement a separate function for Windows, that's also a viable option.
I am willing to try and go down that path, although I'm not a very experienced lisper.