Re: testsuite under wine

Le 23/12/2022 à 11:36, NightStrike a écrit :
> On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <[email protected]> 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