`call-process', to a string [Was: Re: Automatically set eww-download-directory according xdg dir]

[Garreau\, Alexandre]

On 2018-10-29 at 20:54, Garreau, Alexandre wrote:
>     (substring
>      (with-temp-buffer
>        (call-process "xdg-user-dir" nil t nil "DOWNLOAD")
>        (buffer-string))
>      0 -1)
>
> I am not sure this is the simplest way to call a process and get its
> output as string, without using the shell (there seem to be a
> shell-command-to-string, but no call-process-to-string, writing another
> mail about this).

What would it be?

In the `call-process' docstring related to the argument about output,
there’s nothing related to a string:

> Insert output in DESTINATION before point; t means current buffer; nil for 
> DESTINATION
>  means discard it; 0 means discard and don’t wait; and ‘(:file FILE)’, where
>  FILE is a file name string, means that it should be written to that file
>  (if the file already exists it is overwritten).
> DESTINATION can also have the form (REAL-BUFFER STDERR-FILE); in that case,
> REAL-BUFFER says what to do with standard output, as above,
> while STDERR-FILE says what to do with standard error in the child.
> STDERR-FILE may be nil (discard standard error output),
> t (mix it with ordinary output), or a file name string.

I also notice it is not documented that DESTINATION may be a buffer, in
which case the output is inserted in the said buffer (I checked).

Wouldn’t it be useful and reasonable if `call-process' DESTINATION may
have a value that makes `call-process' return a string, rather than the
exit code?

I’d prefer to use that instead of `shell-command-to-string', as it is
less heavy than invoking the shell, and all its parsing (with
`call-process' it is easier and clearer to specify arguments with spaces
in them, for instance, or other special characters (will only require
elisp escapes, not foreign shell escpaes)), for that, and
`shell-command' docstring seems to reflect that idea:
> In Elisp, you will often be better served by calling ‘call-process’ or
> ‘start-process’ directly, since it offers more control and does not impose
> the use of a shell (with its need to quote arguments).