bug#33344: 26.1; doc-view bounding-box recognition doesn't work on path names with spaces

[Eli Zaretskii <eliz@gnu.org>]

> From: Glenn Morris <rgm@gnu.org>
> Cc: trent2@web.de,  33344@debbugs.gnu.org
> Date: Wed, 14 Nov 2018 13:14:39 -0500
> 
> Eli Zaretskii wrote:
> 
> > I don't disagree, but that's not the point.  The point is that this
> > code was written to use the shell, and it works.  Turning it upside
> > down because it failed to quote a single argument risks introducing
> > bugs and backward incompatibilities for what IMO is a very small gain.
> 
> I don't think there's a mystery or grand design here. People sometimes
> just reach for "shell-command" when they want to run an external
> process, without thinking about the details.

Yes, of course.  My point, again, is that this is how it worked till
now, so it is de-facto how people are used to it.

> "sh -c STUFF" is the same as just STUFF unless STUFF relies on some
> shell feature like globbing. If STUFF doesn't require any shell
> features then calling it via a shell is at best inefficient and at
> worst harmful (if the shell mishandles any portion of STUFF, as happens here).
> It is clear by inspection that this particular call does not require
> shell features, so it should not go through a shell.

I agree, but again, that's not my point.  My point is that
shell-command and call-process/process-file are subtly different,
beyond how "sh -c" differs from invoking the program directly.  Just
auditing the code to reveal those differences is a significant job,
let alone making sure the differences do or don't matter in this case.
So I questioned the wisdom of investing such an effort (or not
investing it and risking subtle incompatibilities) for such a minor
reason.