Argh, my mistake about top posting again. My email client does not help me
with this by default and I have to manually construct quoting of previous
responses and delete what shouldn't be there (and missed it again). If there's
any way for someone to delete my previous message from the archive, ple
On 2019-09-06 13:35, Andrey Repin wrote:
> CMD escape character is ^, not \
You are correct about the cmd.exe interpretation, so my test cases were
buggy, but Go invokes other executables using CreateProcess directly and
is not subject to the additional set of command line processing rules that
ar
On 9/5/19 9:26 PM, Eric Blake wrote:
> Rather, go is not passing the command line to CreateProcess in the way
> that is unambiguously parseable in the manner expected by
> CommandLineToArgvW.
The specific example I gave is unambiguous and is parsed correctly by
CommandLineToArgvW, so if the goal i
On 9/5/19 5:46 PM, Eric Blake wrote:
> If you start a cygwin process from Windows, then cygwin1.dll is given
> only a single string, which it must parse into argv according to windows
> conventions (if it does not produce the same argv[] as a windows process
> using CommandLineToArgvW, then that's
On 9/5/19 2:05 PM, Eric Blake wrote:
> On 9/5/19 1:31 PM, Stephen Provine via cygwin wrote:
> > Not expected.
> Why not? That obeyed cmd's odd rules: The moment you have a " in the
> command line, that argument continues until end of line or the next "
> (reg
On 2019-09-04 23:29, Brian Inglis wrote:
> As standard on Unix systems, just add another level of quoting for each level
> of
> interpretation, as bash will process that command line, then bash will process
> the script command line.
My mistake - I'm very aware of the quoting rules, yet in my tes
On 2019-09-04 10:20, Brian Inglis wrote:
> and ask if you really expect anyone else to use or reproduce this insanity,
> rather than a sane POSIX parser?
I know it's insanity, but it's insanity that almost all Windows programs
inherit and
implement consistently enough because they use standard li
On 2019-08-30 21:58, Brian Inglis wrote:
> Not being in the same Cygwin process group and lacking the appropriate
> interface
> info indicates that the invoker was not Cygwin.
Should I interpret this to mean the "winshell" parameter is not an accurate
statement of what I thought it was for and be
> Cygwin command line parsing has to match Unix shell command line processing,
> like argument splitting, joining within single or double quotes or after a
> backslash escaped white space characters, globbing, and other actions normally
> performed by a shell, when any Cygwin program is invoked fro
The standard rules for Microsoft command line processing are documented here:
https://docs.microsoft.com/en-us/previous-versions/17w5ykft(v=vs.85)
The Cygwin code for command line processing is in dcrt0.cc, function build_argv.
The behaviors do not match. For instance, given a test.sh script
On 8/26/2019 1:33 PM, Ken Brown wrote:
> I don't think you understand the logic change in that commit. An attempt to
> create an existing directory would already fail before that commit; the
> failure would occur in the call to fh->mkdir(). The commit in question
> simply guarantees that the e
bject: Re: Future setup regression caused by 'mkdir: always
check-for-existence' commit
On 8/26/2019 11:25 AM, Stephen Provine via cygwin wrote:
> After this change (commit b0c033bf3fae810b9e5a5c69f17bd4de63725691), the Git
> for Windows setup (and future Cygwin setups) do not corre
After this change (commit b0c033bf3fae810b9e5a5c69f17bd4de63725691), the Git
for Windows setup (and future Cygwin setups) do not correctly configure bash
features because the post-install step for configuring the /dev directory does
not work any more. It used to be that "mkdir -m 755 /dev" would
13 matches
Mail list logo
