bug#71081: 30.0.50; shell-command-on-region outputs boilerplate text on Windows

[Eli Zaretskii <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Dmitry Gutov <dmitry@gutov.dev>, 71081@debbugs.gnu.org, matt@excalamus.com
> Date: Wed, 22 May 2024 11:45:23 +0000
> 
> The goal is to evaluate a shell script - multi-line string.
> 
> For example, given
> 
> "cd foo
> pwd"
> 
> we need to get the output/value separated from the stderr and stderr
> output.

OK.

> Org mode uses the approach borrowed from `shell-command-on-region' -
> passing the script as input to shell process (we use
> `process-file'). However, as demonstrated by my reproducer, this
> approach generates more than just script output.

Right.

> In theory, we might pass the script as -c '<shell-escaped script body>',

Won't work on Windows, either, because of the newlines.

> When using comint, piping commands to shell process input is the only
> way to keep the shell running as we send it more commands. However, the
> same problem persists - when sending the very first command, cmd.exe
> generates its version data, which we cannot easily distinguish from the
> rest of the output. We cannot easily see stderr either.

The easiest way of solving this conundrum is to create a temporary
batch file, insert all the commands into it, with the first line being

  @echo off

and then submit the name of that batch file to the Windows shell as
the sole command-line argument after shell-command-switch.  So my
recommendation is to do just that, on Windows.