This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Formatting command line arguments when starting a Cygwin process from a native process
- From: Erik Soderquist <ErikSoderquist at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Fri, 6 May 2016 09:17:29 -0400
- Subject: Re: Formatting command line arguments when starting a Cygwin process from a native process
- Authentication-results: sourceware.org; auth=none
- References: <005c01d1a6e2$30270ba0$907522e0$ at metastack dot com> <CACoZoo1LObZ0zu9X5O6dV4cO4jN+GO28bdRbuDkTMdaKHXpVbQ at mail dot gmail dot com> <000101d1a76d$c37c6b80$4a754280$ at metastack dot com>
On Fri, May 6, 2016 at 4:03 AM, David Allsopp wrote:
>
> [With apologies if threading is broken; I erroneously thought as
> the list was not subscriber-only that replies would use reply-all
> and so wasn't subscribed]
Didn't break for me, though that might be google's threading in gmail
rather than standard threading.
> > C:\cygwin64\bin>.\echo.exe -e ^"hello\nworld^"
> > hello
> > world
> >
> > works.
>
> Indeed - but I'm not using cmd, or any shell for that matter
> (that's actually the point) - I am in a native Win32 process
> invoking a Cygwin process directly using the Windows API's
> CreateProcess call. As it happens, the program I have already
> has the arguments for the Cygwin process in an array, but Windows
> internally requires a single command line string (which is not in
> any related to Cmd).
The you are way over my head...
> > However, I've found Windows's interpretation to be inconsistent, so often
> > have to play with it to find what the "right combination" is for a
> > particular instance.
> >
> > I find echoing the parameters to a temporary text file and then using the
> > file as input to be more reliable and easier to troubleshoot, and it
> > breaks apart whether it is Windows cli inconsistencies or receiving
> > program issues very nicely with the text file content as an intermediary
>
> This is an OK tack, but I don't wish to do this by experimentation
> and get caught out later by a case I didn't think of, so what I'm
> trying to determine is *exactly* how the Cygwin DLL processes the
> command line via its source code so that I can present it with my
> argv array converted to a single command line and be certain that
> the Cygwin will recover the same argv DLL.
>
> My reading of the relevant sources suggests that with globbing
> disabled, backslash escape sequences are *never* interpreted (since
> the quote function returns early - dcrt0.cc, line 171). If there is
> no way of encoding the double quote character, then perhaps I have
> to run with globbing enabled but ensure that the globify function
> will never actually expand anything - but as that's a lot of work,
> I was wondering if I was missing something with the simpler
> "noglob" case.
Again, way over my head, I'm currently a shell scripter...
-- Erik
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple