From: Osher Jacob <osherz5@gmail.com>
To: Matt <matt@excalamus.com>
Cc: emacs-orgmode <emacs-orgmode@gnu.org>
Subject: 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/)]
Date: Tue, 17 Jan 2023 21:53:39 +0200 [thread overview]
Message-ID: <CAGsxwFZGTCAG0EEUBaHLJSn+sLXC7iFjYJTdi7XjEftvU8rhRQ@mail.gmail.com> (raw)
In-Reply-To: <185bd43e452.bb3f5419220019.823265614059778953@excalamus.com>
[-- Attachment #1.1: Type: text/plain, Size: 4124 bytes --]
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? | | | | | |
|
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> | | | | | |
|
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 | |
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).
[image: image.png]
Not sure if this nesting is really relevant to the problem at hand, but
thought it could be useful information.
Any ideas on how to proceed from here?
On Tue, Jan 17, 2023 at 3:07 AM Matt <matt@excalamus.com> wrote:
>
> ---- On Mon, 16 Jan 2023 16:40:27 -0500 Matt wrote ---
> > That is, go through the steps to reproduce and before executing the
> block, run `M-: (setq shell-command-switch "/k")'.
>
> Whoa, just re-read this after stepping away and it sounds super
> demanding! Please excuse me, I've been trying to use active voice while
> writing documentation.
>
> Let me try that again:
>
> What happens if you go through the steps to reproduce and run `M-: (setq
> shell-command-switch "/k") before executing the block?
>
[-- Attachment #1.2: Type: text/html, Size: 5897 bytes --]
[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 13297 bytes --]
next prev parent reply other threads:[~2023-01-17 22:12 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-16 16:27 [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/)] Osher Jacob
2023-01-16 21:40 ` Matt
2023-01-17 1:07 ` Matt
2023-01-17 19:53 ` Osher Jacob [this message]
2023-01-18 5:09 ` Matt
2023-01-18 9:05 ` Ihor Radchenko
2023-01-19 16:28 ` Osher Jacob
2023-01-20 4:29 ` Matt
2023-01-20 9:27 ` Ihor Radchenko
2023-01-23 3:12 ` Matt
2023-01-23 11:42 ` Ihor Radchenko
2023-01-26 4:04 ` Matt
2023-01-26 9:51 ` Ihor Radchenko
2023-01-30 6:00 ` Matt
2023-01-30 14:00 ` Ihor Radchenko
2023-01-30 17:08 ` Matt
2023-02-01 12:05 ` Ihor Radchenko
2023-02-01 20:21 ` Matt
2023-01-20 9:24 ` Ihor Radchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGsxwFZGTCAG0EEUBaHLJSn+sLXC7iFjYJTdi7XjEftvU8rhRQ@mail.gmail.com \
--to=osherz5@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=matt@excalamus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).