Boost.Process 0.5: And another minor update
I've uploaded a new version of Boost.Process 0.5 to <http://www.highscore.de/boost/process0.5/>: - First command line argument passed to set_args is used as a path to the executable to start - No escaping of command line arguments anymore with set_args (see <http://article.gmane.org/gmane.comp.lib.boost.devel/236137>) - Updated documentation Boris
I've uploaded a new version of Boost.Process 0.5 to <http://www.highscore.de/boost/process0.5/>:
- First command line argument passed to set_args is used as a path to the executable to start - No escaping of command line arguments anymore with set_args (see <http://article.gmane.org/gmane.comp.lib.boost.devel/236137>) - Updated documentation
Boris Sounds good. It might be beneficial to use mini versions, e.g. 0.5.4,
On 2012-12-09 02:38, Boris Schaeling wrote: though. That would allow people to compare certain aspects with previous versions. Ceterum censeo, well, you know it :-) Regards, Roland
On Sun, 09 Dec 2012 13:57:43 +0100, Roland Bock <rbock@eudoxos.de> wrote:
I've uploaded a new version of Boost.Process 0.5 to <http://www.highscore.de/boost/process0.5/>:
- First command line argument passed to set_args is used as a path to the executable to start - No escaping of command line arguments anymore with set_args (see <http://article.gmane.org/gmane.comp.lib.boost.devel/236137>) - Updated documentation
Boris Sounds good. It might be beneficial to use mini versions, e.g. 0.5.4,
On 2012-12-09 02:38, Boris Schaeling wrote: though. That would allow people to compare certain aspects with previous versions.
True. But then I never expected that I would ship so many mini versions before another review. :) Boris
On Sun, Dec 9, 2012 at 12:38 PM, Boris Schaeling <boris@highscore.de> wrote: > I've uploaded a new version of Boost.Process 0.5 to < > http://www.highscore.de/**boost/process0.5/<http://www.highscore.de/boost/process0.5/> > >: > > - First command line argument passed to set_args is used as a path to the > executable to start > - No escaping of command line arguments anymore with set_args (see < > http://article.gmane.org/**gmane.comp.lib.boost.devel/**236137<http://article.gmane.org/gmane.comp.lib.boost.devel/236137> > >) > - Updated documentation > > Boris > > > ______________________________**_________________ > Unsubscribe & other changes: http://lists.boost.org/** > mailman/listinfo.cgi/boost<http://lists.boost.org/mailman/listinfo.cgi/boost> > Hi Boris, Thanks for your continued work on this library. I'm a little concerned by one of the changes you mentioned however, specifically this one: > 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/everyone-quotes-arguments-the-wrong-way.aspx Thanks.
On Sun, 09 Dec 2012 19:53:41 +0100, Joshua Boyce <raptorfactor@raptorfactor.com> wrote:
[...]I'm a little concerned by one of the changes you mentioned however, specifically this one:
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...
Thanks for the link! The reason why set_args() was changed now was that the example Yakov had provided (see <http://article.gmane.org/gmane.comp.lib.boost.devel/236075>) didn't work. The more important point he made was that the current "non-escaping" behavior increases the set of possible arguments (while before certain things didn't work because escaping interfered). But I'll have a look at the link to see whether there are any counterarguments. :) Boris
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. 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 /?): [...] 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
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
participants (4)
-
Boris Schaeling -
Joshua Boyce -
Roland Bock -
Yakov Galka