Osher Jacob <oshe...@gmail.com> writes: > On Wed, Jan 18, 2023 at 11:05 AM Ihor Radchenko <yanta...@posteo.net> wrote: > >> 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.
... which means that I did not dig deep enough. Apparently, `process-file' is not passing the file to cmdproxy.exe. It calls `call-process', which reads file and passes its contents as input. So, we don't need to do awkward manoeuvring with "&" and making the src block contents into a one-liner. It's about understanding how cmdproxy.exe handles stdin. > 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. This looks like the way to go. For non-Windows systems we have some test coverage. I am wondering if we should add tests for powershell and cmdproxy. Though only users with Windows will actually be able to run those. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
