This is the mail archive of the
mailing list for the Cygwin project.
Re: Formatting command line arguments when starting a Cygwin process from a native process
- From: Andrey Repin <anrdaemon at yandex dot ru>
- To: "David Allsopp" <dra-news at metastack dot com>, cygwin at cygwin dot com
- Date: Fri, 6 May 2016 17:20:40 +0300
- 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>
- Reply-to: cygwin at cygwin dot com
Greetings, David Allsopp!
> [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]
As long as your mail client is fine, you're fine.
> 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).
Then all you need is a rudimentary quoting.
The rest will be handled by getopt when the command line is parsed.
>> 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.
The point being, when you pass the shell and enter direct process execution,
you don't need much of shell magic at all.
Shell conventions designed to ease interaction between system and operator.
But you have a system talking to the system, you can be very literal.
With best regards,
Friday, May 6, 2016 17:18:00
Sorry for my terrible english...
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple