From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp-11.smtpout.orange.fr [80.12.242.11]) by sourceware.org (Postfix) with ESMTPS id 0F5EE3851405 for ; Fri, 23 Dec 2022 12:43:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0F5EE3851405 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orange.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=orange.fr Received: from [192.168.1.5] ([90.116.254.181]) by smtp.orange.fr with ESMTP id 8hOCpBQLQ8UoF8hOCpcOGd; Fri, 23 Dec 2022 13:43:08 +0100 X-ME-Helo: [192.168.1.5] X-ME-Date: Fri, 23 Dec 2022 13:43:08 +0100 X-ME-IP: 90.116.254.181 Message-ID: Date: Fri, 23 Dec 2022 13:43:04 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: testsuite under wine Content-Language: en-US To: NightStrike , jcb62281@gmail.com Cc: Jacek Caban , fortran@gcc.gnu.org, "gcc@gcc.gnu.org" , dejagnu@gnu.org References: <639FE88D.7090408@gmail.com> <7cb45ab2-cc6e-c502-5592-51ffabcbc6f8@codeweavers.com> <63A3DF0E.1050902@gmail.com> From: Eric Pouech In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,FREEMAIL_FROM,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Le 23/12/2022 à 11:36, NightStrike a écrit : > On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer wrote: >> NightStrike wrote: >>> [...] >>> Second, the problems with extra \r's still remain, but I think we've >>> generally come to think that that part isn't Wine and is instead >>> either the testsuite or deja. So I'll keep those replies to Jacob's >>> previous message. >>> >> Most likely, it is a combination of the MinGW libc (which emits "\r\n" >> for end-of-line in accordance with Windows convention) and the kernel >> terminal driver (which passes "\r" and translates "\n" to "\r\n" in >> accordance with POSIX convention). Wine, short of trying to translate >> "\r\n" back to "\n" in accordance with POSIX conventions (and likely >> making an even bigger mess---does Wine know if a handle is supposed to >> be text or binary?) cannot really fix this, so the testsuite needs to >> handle non-POSIX-standard line endings. (The Rust tests probably have >> an outright bug if the newlines are being duplicated.) > You may be onto something here. I ran wine under script as `script -c > "wine64 ./a.exe" out` (thanks, Arsen!), and it had the same extra \r > prepended to the \r\n. I was making the mistake previously of running > wine manually and capturing it to a file as `wine64 ./a.exe > out`, > which as several have pointed out in this thread, that would disable > the quirk, so of course it didn't reveal any problems. I'm behind, > but I'll catch up to you guys eventually :) > > So at least we know for sure that this particular instance of extra > characters is coming from Wine. Maybe Wine can be smart enough to > only translate \n into \r\n instead of translating \r\n into \r\r\n. > Jacek / Eric, comments here? I'm happy to try another patch, the > first one was great. > actually, it depends on how the file has been opened by the application. if it's done in binary mode, no \n => \r\n translation takes place but it the file is opened in text mode, wine just does what the application requires, which is \n => \r\n translation (and by default, stdout and stderr are opened in text mode) IMO, you should not expect more from Wine. Wine's goal is to run windows application on Unix ; it's not to run windows applications on Unix and requiring that they behave as they had been written for Linux semantics anyway, we (wine) have to go back to blackboard to figure out a solution for disabling nicely conhost in the meantime, you could use (without any patch to wine), some wrapper (bash) script like: #!/bin/bash # assumes wine is in $PATH case "$1" in     --unix-raw) shift; cat | wine $* 1> >(tee /dev/null) 2> >(tee /dev/null >&2);;     --unix-lf)  shift; cat | wine $* 1> >(tee /dev/null | sed 's/\r$//' ) 2> >(tee /dev/null | sed 's/\r$//' >&2);;     *) wine $*;; esac using --unix-raw will just disable conhost (hence shall remove most of the ansi sequences reported) using --unix-lf will also disable conhost and replace \r\n with \n this shall put wine in the behavior as you expect, and still allow using proper redirection and piping on the shell script if needed (without alterning wine's behavior) (this could be further improved by not adding a pipe for fd:s that are not tty, or adapted to be triggered when, say, TERM=dumb) HTH