delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2016/05/06/10:35:42

X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
:list-unsubscribe:list-subscribe:list-archive:list-post
:list-help:sender:date:from:reply-to:message-id:to:subject
:in-reply-to:references:mime-version:content-type
:content-transfer-encoding; q=dns; s=default; b=DvgPi1j/59Q8TEdL
CSWU6zDYWZ1Asgag+kz6oipq7ivg1ugILpwAX0pecN55kuiZwAzSUXxd943O+ot7
27Sv5T1PQGjo0BnOzsjJNQjFvAEI8yNTe+PQziQtFZTVf+jRvRDrlq4cz4UqgsvD
enQjQjTDe+Kcd9GjNGGagwJ7Z2I=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
:list-unsubscribe:list-subscribe:list-archive:list-post
:list-help:sender:date:from:reply-to:message-id:to:subject
:in-reply-to:references:mime-version:content-type
:content-transfer-encoding; s=default; bh=l93oUNhnNN+Bhp8b7/JEt4
CMTyw=; b=e6oBrv7PK0saFnepLYpTYh2vUDwrs5t059UBBMZzf6ok3Yu23AX3K3
D72h1OdTxxV5BaWa2aybAtffhQjLS7B5qki0sHIWzEkrjAwjItlnTOh6xpwZGD+o
t0rzUV+FsnobnmMQ5xjM1h0PogPKGta06IQcmnEA4XipYnRrnjtbs=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=4.0 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,KAM_THEBAT,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=H*UA:Bat!, H*x:Bat!, Repin, repin
X-HELO: smtp.ht-systems.ru
Date: Fri, 6 May 2016 17:20:40 +0300
From: Andrey Repin <anrdaemon AT yandex DOT ru>
Reply-To: cygwin AT cygwin DOT com
Message-ID: <967954968.20160506172040@yandex.ru>
To: "David Allsopp" <dra-news AT metastack DOT com>, cygwin AT cygwin DOT com
Subject: Re: Formatting command line arguments when starting a Cygwin process from a native process
In-Reply-To: <000101d1a76d$c37c6b80$4a754280$@metastack.com>
References: <005c01d1a6e2$30270ba0$907522e0$@metastack.com> <CACoZoo1LObZ0zu9X5O6dV4cO4jN+GO28bdRbuDkTMdaKHXpVbQ AT mail DOT gmail DOT com> <000101d1a76d$c37c6b80$4a754280$@metastack.com>
MIME-Version: 1.0
X-IsSubscribed: yes

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,
Andrey Repin
Friday, May 6, 2016 17:18:00

Sorry for my terrible english...


--
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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019