From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75108 invoked by alias); 5 Sep 2019 23:45:49 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 75100 invoked by uid 89); 5 Sep 2019 23:45:48 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_SPF_HELO,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=no version=3.3.1 spammy=reproduces X-HELO: NAM01-SN1-obe.outbound.protection.outlook.com Received: from mail-eopbgr820103.outbound.protection.outlook.com (HELO NAM01-SN1-obe.outbound.protection.outlook.com) (40.107.82.103) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 05 Sep 2019 23:45:47 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RRMQoFUjcJavpYFbEC8vmsRUZy4+zSIsFGL1SOBxO/piKvnym3w6NKW/iw94QNRQ3qtXB6+EpNlel0xHYhAMAA1JAO0XCwH2Qj7dGMeDoR+znS7txIImxZeDXA/4UEB3BwGbIpytcNCGKTWXYBuZ5Ivs2jGwJ/0wUci/Nmld+VRbbGsBnXeIG7pxHskZkSGF7XFmpMm3x11WqHFUGosbPpJWXqS4AtRhZPQaooZbI5FE6+s5dRL1WnAEaF+ZUT+3B0ayAFahzInUupYEbaXLydQ67BPtpFDXkEIk1AnWHqmtzIEtA/S2Sw65F6NfgwJm2V9eOzKvwjmNBMKsDPm2iQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EqNj0WYSOM1w6V6rig/xKUm2Xc0gM+xHPcBw0wpmZ60=; b=WnzsID5upW2z7i8l/lGO3huY2Dkb87AfphaqLbQZ+ZkhBDbBSndUUwFw3X/FYQrZ1HCwchpSU5TPuCRhSsBLQMgws6z7t7rqGR++w+76/oZmr9m49ts6FvZhB38uHGEdH7Axq3zw3rD8DAhveu3oUNXEWDTnkZI0KX2YPEEMIKgzMY2JFQy1MvVtJ7BLzdLuDvJRqci29ccKtsvjw/eTYY5FQyF+xgDlMXALRBKOCYrWdfgcUDPdgsvf63/r2NTqqhSUSQBanu1I4VEOSMs6t7HU8kRmIPRDdpZNuI6usaW72qgZa4hlfTL1GQLtwONQRTQLu2YSUAemKf2gp8DwCg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EqNj0WYSOM1w6V6rig/xKUm2Xc0gM+xHPcBw0wpmZ60=; b=I4C/Z0E8tHaBzRA1vdN/XwQJHHhCON9nAMfRgdxOXBxwzbd+oZmpKwdaD1adXhCN27wPoEeET75MV0bu3vH0txswCfN2uisEMuUKTImDn0xACXvguV/Sf5U1T9ZgsofjYqyiTg5M4V9pDZodrGAhpkF0I2GLlVh3hyJgALmiWCc= Received: from MWHPR21MB0845.namprd21.prod.outlook.com (10.173.51.139) by MWHPR21MB0704.namprd21.prod.outlook.com (10.175.142.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.4; Thu, 5 Sep 2019 23:45:44 +0000 Received: from MWHPR21MB0845.namprd21.prod.outlook.com ([fe80::3085:a037:7cbc:be5]) by MWHPR21MB0845.namprd21.prod.outlook.com ([fe80::3085:a037:7cbc:be5%5]) with mapi id 15.20.2241.014; Thu, 5 Sep 2019 23:45:44 +0000 From: "Stephen Provine via cygwin" Reply-To: Stephen Provine To: "cygwin@cygwin.com" Subject: RE: Command line processing in dcrt0.cc does not match Microsoft parsing rules Date: Thu, 05 Sep 2019 23:45:00 -0000 Message-ID: References: In-Reply-To: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stephpr@microsoft.com; x-ms-oob-tlc-oobclassifiers: OLM:9508; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tqbRAuEkEEOLiqJgDjvfPLARh27pLdnQBwhVBuqzCoNhjZmWo7p2bgWfnUTYfnZx6mdW4AWp3hXq9QvbNqtjdg== X-SW-Source: 2019-09/txt/msg00049.txt.bz2 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 a bug in cygwin1.dll). But on top > of that, if you are using cmd.exe to generate your command line, then > you must use proper escaping, otherwise, cmd.exe can produce a command > line that has unexpected quoting in the string handed to > CommandLineToArgvW, and the Windows parsing when there are unbalanced > quotes can be screwy Great explanation, it's very helpful. I've been using cmd.exe to generate the command line for my tests, but the original problem was when my compiled Go binary directly executes another Windows process using the Win32 APIs like CreateProcess directly. Here's a simple Go program that reproduces the issue: 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.Stderr =3D os.Stderr if err :=3D cmd.Run(); err !=3D nil { log.Fatal(err) } } The output of this process is: foo bar\baz bat 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:\\cygwin64\\bin\\bash.exe test.sh foo bar\\\"baz bat" So unless I'm missing something, bash.exe is not interpreting the command l= ine following the rules pointed to by the documentation for CommandLineToArgvW. Thanks, Stephen -- 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