On Sat, Jul 26, 2014 at 10:27:54AM +0200, Ola Lundqvist wrote:
> Thanks for the extensive explanation.
>
> I wonder why I did not do this vrfycmd as the others. Probably because I
> want to know the results. Or maybe more likely that it is a patch from
> someone else.
Yeah, it looks like this was a patch sent in bug #143095 (from 2002, and
I can't remember what patches people sent me then either :)
> Would it be an issue if we use system("cmd args") instead of the array for
> you?
For my immediate use case that should work ok, and dscverify is also a
fairly simple command, where the only thing you'd ever need to quote
would be if you were silly enough to have spaces in the path to your
keyring files.
But it's always hard to guess what other people might want to do, or
what tools might replace dscverify in the future for this job, and
once we change it to system("$cmd $args") we lose the chance to be
be able to do it this way in the future if needed, without making a
more incompatible change to the existing user config.
I mainly picked this as my first choice because:
- We are able to do it safely and backward compatibly now.
- I have been burned by *needing* to do it this way for tools like
gitpkg and cowpoke, which have to pass options to things like
pbuilder and dpkg which do have --option="thing1 thing2 thing3"
which must be quoted and do contain spaces (or other characters
which could be special to a perl system call, like '|' in the
case of pbuilder). So it's a bit more "future proof".
- It's a defensive coding habit of mine to use the 2 arg form of
system() in perl anywhere that things passed to it come from an
'outside source' (but in this case we do already have to trust
the admin that creates the config file anyway).
The only advantages I see to going with system("cmd arg") are:
- It's a little more consistent with the overrides for the other
existing commands.
- You'd have the option to pass it to cmdaction() like the rest
if there was some reason to change things to do that.
Neither case has a clear showstopper I can see that isn't based on
some hypothetical future problem though, so either of them should
work just as well in practice for me today.
Cheers,
Ron
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
