On Wed, Dec 12, 2012 at 6:25 PM, Yakov Galka <ybungalobill@gmail.com> wrote:
On Sun, Dec 9, 2012 at 8:53 PM, Joshua Boyce <raptorfactor@raptorfactor.com>wrote:
On Sun, Dec 9, 2012 at 12:38 PM, Boris Schaeling <boris@highscore.de> wrote:
No escaping of command line arguments anymore with set_args
I'm concerned because under Windows at least, the way that command line arguments are escaped is quite important (and also difficult to get right). Does your library correctly handle all the example cases given in the article below?
http://blogs.msdn.com/b/twistylittlepassagesallalike/archive/2011/04/23/ever...
Good article, but its relevance to the scope of this library is doubted. It deals with "the correct way of passing arguments to applications that use CommandLineToArgvW", yet admits that not all applications use this functions and in fact a very frequently used one (cmd.exe) falls within this category.
If you're writing Windows GUI applications your entry point will typically be wWinMain/WinMan rather than main/wmain, so you don't have access to an argv/argc pair. At this point, the easiest option if you want to access your command line in this manner (to make parsing easier on yourself, or to share logic with some component which is written to take input in such a format so as to support both entry point 'types') is to use CommandLineToArgvW. http://msdn.microsoft.com/en-us/library/windows/desktop/ms633559(v=vs.85).as... It's not like this is some corner case I'm talking about, this is a very commonly used API used in lots of idiomatic and perfectly well formed Windows applications. I think that being able to use Boost.Process to launch processes which use this API and expect the results it gets to be correct is not unreasonable.
It also describes the way cmd.exe processes quotation marks in the command line *written in the command prompt and batch files*, which is irrelevant to the subject of passing command lines *to* cmd.exe. cmd.exe interprets the quotation marks in its own command line in a different way (from cmd.exe /?):
I wasn't trying to draw attention to the section on cmd.exe, I was trying to draw attention to the section on correctly quoting arguments for a call to CreateProcess. I assumed that would be clear from the context, but if it wasn't then I apologize. I meant only for Boris to address the first half of the article. (e.g. In the conclusion of the article, to follow step 1 of the Do's, but not step 2.)
[...] where the following logic is used to process quote (") characters:
1. If all of the following conditions are met, then quote characters on the command line are preserved: [...] 2. Otherwise, old behavior is to see if the first character is a quote character and if so, strip the leading character and remove the
last
quote character on the command line, preserving any text after the last quote character.
As per Boost.Process, all this means that you cannot get all: 1) passing arbitrary arguments to any application and 2) do it transparently to the user 3) using a uniform interface. As I said, in my opinion, trading 2 for 1 and 3 is the most sensible compromise.
-- Yakov
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost