From: Osher Jacob <osherz5@gmail.com>
To: Ihor Radchenko <yantar92@posteo.net>, 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: Thu, 19 Jan 2023 18:28:09 +0200 [thread overview]
Message-ID: <CAGsxwFbwL_BXd82pyhpNYdiswCYZ9xDRgq2xCc1icFfZxwbX8Q@mail.gmail.com> (raw)
In-Reply-To: <87ilh48b6p.fsf@localhost>
[-- Attachment #1: Type: text/plain, Size: 4038 bytes --]
Thanks for the suggestions!
On Wed, Jan 18, 2023 at 7:09 AM Matt <matt@excalamus.com> wrote:
>
> 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'.
>
On Wed, Jan 18, 2023 at 11:05 AM Ihor Radchenko <yantar92@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.
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.
Do any of these options sound like they could work well?
[-- Attachment #2: Type: text/html, Size: 5800 bytes --]
next prev parent reply other threads:[~2023-01-19 16:29 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
2023-01-18 5:09 ` Matt
2023-01-18 9:05 ` Ihor Radchenko
2023-01-19 16:28 ` Osher Jacob [this message]
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=CAGsxwFbwL_BXd82pyhpNYdiswCYZ9xDRgq2xCc1icFfZxwbX8Q@mail.gmail.com \
--to=osherz5@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=matt@excalamus.com \
--cc=yantar92@posteo.net \
/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).