Re: [BUG] ob-shell doesn't evaluate last line on Windows (cmd/cmdproxy) [9.6.1 ( @ c:/Users/Osher/AppData/Roaming/.emacs.d/elpa/org-9.6.1/)]

[Matt <matt@excalamus.com>]

 ---- On Thu, 19 Jan 2023 11:28:09 -0500  Osher Jacob  wrote --- 
 
 > 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

They're good ideas and, I agree, aren't ideal.  

 >  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"))))))

Your original proposal was reasonable and looks even more so now. 
 
 > 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.

Agreed, I like its simplicity.  Tests are a first step and they all pass with your suggested change.

 > 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.
 > Do any of these options sound like they could work well?

I agree, putting in the newline is simple and it would be easy enough to create a separate path for Windows/cmd if it were a problem.

I wonder if it might make sense to move where the trimming happens so that the body passed into `org-babel-sh-evaluate' is ready to go and we could handle the cmd case separately and earlier (by inserting the newline there)?

I appreciate you taking the time to explore and for being open to what feels like me over-thinking it :)

I'll be away from the keyboard for a few days and I look forward to getting this wrapped up for you.  Meanwhile, I'm curious if Ihor or others have advice.