On 2019-09-09 12:26, Duncan Roe wrote:
> On Mon, Sep 09, 2019 at 11:57:21AM -0500, Eric Blake wrote:
>> On 9/9/19 11:47 AM, Stephen Provine via cygwin wrote:
>>> Argh, my mistake about top posting again. My email client does not help me
>>> with this by default and I have to manually construct quot
Greetings, Duncan Roe!
> On Mon, Sep 09, 2019 at 11:57:21AM -0500, Eric Blake wrote:
>> On 9/9/19 11:47 AM, Stephen Provine via cygwin wrote:
>> > 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 previo
Hi Eric,
On Mon, Sep 09, 2019 at 11:57:21AM -0500, Eric Blake wrote:
> On 9/9/19 11:47 AM, Stephen Provine via cygwin wrote:
> > 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 an
On 9/9/19 11:47 AM, Stephen Provine via cygwin wrote:
> 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 f
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
t algorithm (Go isn't right, what about Node, Python, etc...) But
I'm not going to push on this point as I can work around it for my case.
Thanks,
Stephen
-Original Message-
From: Andrey Repin
Sent: Friday, September 6, 2019 1:35 PM
To: Stephen Provine ; cygwin@cygwin.com
Subje
On 2019-09-05 16:01, Stephen Provine via cygwin wrote:
> 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 li
Greetings, Stephen Provine!
> 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
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 6:45 PM, Stephen Provine via cygwin wrote:
>
> To prove it is not going through cmd.exe, I debugged the Go program
> to the point that it calls the Win32 CreateProcess function, and the
> first two arguments are:
>
> lpApplicationName: "C:\\cygwin64\\bin\\bash.exe"
> lpCommandLine: "C:
On Thu, 5 Sep 2019 23:45:44, "Stephen Provine via cygwin" wrote:
package main
import (
"log"
"os"
"os/exec"
)
func main() {
cmd :=3D exec.Command("C:\\cygwin64\\bin\\bash.exe", "test.sh", "foo",
"ba=
r\"baz", "bat")
cmd.Stdout =3D os.Stdout
cmd.S
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 5:01 PM, Stephen Provine via cygwin wrote:
> 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 lin
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 "
> (regardless of how many \ precede the ").
On 9/5/19 1:31 PM, Stephen Provine via cygwin wrote:
> My mistake - I'm very aware of the quoting rules, yet in my test script for
> this
> scenario I forgot to quote the arguments. However, if POSIX rules are being
> implemented, there is still something I didn't expect. Here's my bash script:
>
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 17:46, Stephen Provine wrote:
> 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
> im
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-09-03 10:38, Stephen Provine wrote:
> 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 a
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
Greetings, Stephen Provine!
> 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 mat
On 2019-08-30 14:59, Stephen Provine wrote:
>> 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
>> performe
> 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
On 2019-08-30 13:16, Stephen Provine via cygwin wrote:
> 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.
> T
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
25 matches
Mail list logo
