From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118403 invoked by alias); 24 Oct 2016 13:24:26 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 118359 invoked by uid 89); 24 Oct 2016 13:24:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=grasp X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 24 Oct 2016 13:24:17 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1byfEZ-00076m-Nf for gdb-patches@sourceware.org; Mon, 24 Oct 2016 09:24:12 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48669) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byfET-00074Q-FK; Mon, 24 Oct 2016 09:24:05 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2143 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1byfES-00063H-4J; Mon, 24 Oct 2016 09:24:04 -0400 Date: Mon, 24 Oct 2016 13:24:00 -0000 Message-Id: <83oa29518t.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves CC: gdb-patches@sourceware.org, samsurfer117@gmail.com In-reply-to: (message from Pedro Alves on Mon, 24 Oct 2016 13:36:34 +0100) Subject: Re: CYGWIN file input redirection Reply-to: Eli Zaretskii References: <83twcxn3ne.fsf@gnu.org> <8360ot3kzq.fsf@gnu.org> <83zim523ch.fsf@gnu.org> <83eg38rarq.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg00664.txt.bz2 > Cc: samsurfer117@gmail.com > From: Pedro Alves > Date: Mon, 24 Oct 2016 13:36:34 +0100 > > On 10/22/2016 10:30 AM, Eli Zaretskii wrote: > > Ping! Is this OK to push to master, please? > > I think this should have a NEWS entry. Yes, I thought about this myself. Will do. > Since on Windows, programs are expected to handle redirection > themselves ??? No, they don't (I believe you thought about wildcard expansion?). Redirection on Windows shell command line works like on Unix: the shell invokes the program with standard streams redirected according to the redirection symbols. Which is exactly what this code emulates inside GDB. > isn't there a chance that this will make it a bit > harder to debug such redirection code in inferiors that > do it themselves? E.g., imagine if you're debugging cmd.exe's > redirection code. Or maybe even debugging this new code > in gdb itself? Do we need a knob to be able to disable > this feature? I'm not sure I see the problem. If you debug GDB's redirection code, you will probably not redirect that GDB's standard streams, right? IOW, you would > gdb ./gdb.exe (top-gdb) run foo.exe (gdb) run < bar > baz Right? Or did you mean something else? > It'd be nice to add comments mentioning what syntax works and doesn't > work. Is there something users should know about syntax, that > should be added to the manual? The code is supposed to support everything cmd.exe supports, and nothing else. Ah, I see I didn't implement the likes of "2>&1". Will do. The only thing beyond what cmd.exe supports is that one can use Unix-style forward slashes in redirected file names, which comes in handy because GDB's file-name completion helps. Not sure if this should be in the manual. WDYT? > Ideally some test would "prove" this all works, which would > also make it possible to more confidently change the implementation > later on if we find it necessary. It's been years since I'd tried to > run the testsuite for mingw gdb (under cygwin/msys/msys2 of course) > and I have no idea whether people are doing that nowadays. I have > the impression that maybe no one is.. And then, I can't seem to > find any existing test that exercises redirection, even > on Unix... :-/ Oh well. Right. I don't have a setup for running the test suite. I did, of course, test the code manually. > >> + if (inferior_io_terminal > >> + && !(inf_stdin != INVALID_HANDLE_VALUE > >> + && inf_stdout != INVALID_HANDLE_VALUE > >> + && inf_stderr != INVALID_HANDLE_VALUE)) > > I find these double-negatives hard to read. I'd suggest: > > if (inferior_io_terminal > && (inf_stdin == INVALID_HANDLE_VALUE > || inf_stdout == INVALID_HANDLE_VALUE > || inf_stderr == INVALID_HANDLE_VALUE)) Interesting, I actually find the latter harder to grasp. The former says "if not all of the handles are valid". I can add a macro VALID_HANDLE, if that would help. Thanks for the review, I will add the missing bits and fixes and resubmit.