From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp-24.smtpout.orange.fr [80.12.242.24]) by sourceware.org (Postfix) with ESMTPS id EC5123858D1E for ; Thu, 22 Dec 2022 08:40:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EC5123858D1E 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 8H7lpFcKCPNsN8H7lpnW4Y; Thu, 22 Dec 2022 09:40:23 +0100 X-ME-Helo: [192.168.1.5] X-ME-Date: Thu, 22 Dec 2022 09:40:23 +0100 X-ME-IP: 90.116.254.181 Message-ID: <0bfd557c-aa07-dac5-86f4-104e71593212@orange.fr> Date: Thu, 22 Dec 2022 09:40:21 +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 To: jcb62281@gmail.com, Jacek Caban Cc: fortran@gcc.gnu.org, NightStrike , DejaGnu mailing list References: <639FE88D.7090408@gmail.com> <7cb45ab2-cc6e-c502-5592-51ffabcbc6f8@codeweavers.com> <63A3DA04.4060804@gmail.com> Content-Language: en-US From: Eric Pouech In-Reply-To: <63A3DA04.4060804@gmail.com> 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,GB_TO_NAME_FREEMAIL,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 22/12/2022 à 05:16, Jacob Bachmeyer a écrit : > >> I think that it would not be enough. The way Windows consoles work is >> that we manage complete internal screen buffer and emit output that >> synchronizes the buffer with Unix terminal inside conhost.exe >> process. It means that its output heavily processed and may be very >> different from what application writes to its console handle. While >> escape codes discussed in this thread are the most prominent >> difference (and that part could, in theory, be improved on our side), >> there are more differences. For example, if application writes >> "\rA\rB\rC", conhost will process it, update its internal buffer >> which changes just one character and cursor position, and emit >> sequence to update it in Unix terminal, which could be just "\rC" (or >> even "C" if cursor was already at the beginning of the line). Another >> example would be long lines: conhost will emit additional EOLs >> instead of depending on embedder to wrap the line. > > So conhost is essentially a Wine-specific screen(1) in that sense, > except that it translates Windows screen buffer manipulations instead > of VT100 escape codes?  As I understand ncurses also implements most > of this; perhaps simply delegating output to ncurses would solve the > problem?  If output were simply delegated to ncurses, (as I > understand) setting TERM=dumb should be effective to eliminate escape > codes from the output, since the "dumb" terminal does not support them. unfortunately, things are not as simple as that: on one hand we need to mimic Windows behavior, and on the other hand let apps running in wine behave like regular posix applications (Note: conhost(.exe) is not wine specific, it's part of the way windows handle the console input/output) but I agree that wine should provide a (simple) way to disable windows' console for cases like this > > Alternately, could we have a "transparent" mode in conhost where most > processing is bypassed?  Setting TERM=dumb in the environment could > reasonably activate this mode, or some other Wine-specific setting > could be used.  (maybe "WINETERM=raw"?) an alternate solution to Jacob's patch is to run wine with none of the fd 0,1,2 opened on a (p)tty (assuming dejagnu doesn't require fd 0 from console). So something like ./wine what_ever_you_need | tee /dev/null 2>1 < /dev/null would do HTH