[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#33344: 26.1; doc-view bounding-box recognition doesn't work on path
bug#33344: 26.1; doc-view bounding-box recognition doesn't work on path names with spaces
Wed, 14 Nov 2018 21:29:41 +0200
> From: Glenn Morris <address@hidden>
> Cc: address@hidden, address@hidden
> 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
bug#33344: 26.1; doc-view bounding-box recognition doesn't work on path names with spaces, Robert Spillner, 2018/11/22