Re: [boost] Boost.Process 0.5: And another minor update

Subject: Re: [boost] Boost.Process 0.5: And another minor update
From: Joshua Boyce (raptorfactor_at_[hidden])
Date: 2012-12-13 16:16:17

On Wed, Dec 12, 2012 at 6:25 PM, Yakov Galka <ybungalobill_at_[hidden]> wrote:

> On Sun, Dec 9, 2012 at 8:53 PM, Joshua Boyce
> <raptorfactor_at_[hidden]>wrote:
>
> > On Sun, Dec 9, 2012 at 12:38 PM, Boris Schaeling <boris_at_[hidden]>
> > 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/everyone-quotes-arguments-the-wrong-way.aspx
> >
>
> 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).aspx

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
>