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

[Ihor Radchenko <yantar92@posteo.net>]

Eli Zaretskii <eliz@gnu.org> writes:

>> On Windows, it yields
>> 
>> "foo"
>
> Yes, because the Windows shell doesn't support command lines with
> embedded newlines, so it ignores everything past the first newline.
> (Actually, there are complicated tricks to do that, but I'll spare
> you.)

Should it be documented in the docstring of `shell-command-to-string'?
Currently, it only mentions `shell-quote-argument' and the current
behaviour is not expected - there is nothing indicating that one should
be careful about newlines (or any other characters passed to system
shell).

> Instead, you should do this on Windows:
>
>   (shell-command-to-string "echo foo && echo bar")
>
> This is the documented method of invoking cmd.exe with multiple
> commands.

Maybe. But `shell-command-on-region' does work with multi-line commands,
so it all boils down to implementation details, which are not really
described... Why would anyone assume that `shell-command-to-string' is
passed as an argument to cmd.exe and not piped as input? Or wise
versa. Or maybe by some other means - all the cases have subtle
differences. (not just on Windows; on Linux as well; more over, on
Linux, different shells have different behaviors wrt input/command
argument/script file).

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