Re: testsuite under wine

Re: testsuite under wine

[Thomas Koenig]

On 17.12.22 01:26, NightStrike wrote:
> On Fri, Dec 16, 2022 at 1:44 AM Thomas Koenig <tkoenig@netcologne.de> wrote:
>>
>> On 16.12.22 03:20, NightStrike via Fortran wrote:
>>
>>> When I run the testsuite under wine, I'm getting a lot of ANSI escape
>>> sequences.  We had fixed this long ago, but it seems to be back.  Any
>>> idea what I should change in my configuration to have this not happen?
>>
>> This should probably be fixed properly in some *.exp file, but you can
>> try setting the GCC_COLORS environment variable to an empty string
>> before running the test.
> 
> That didn't help.  It looks like this is always escape 25h to start
> the output and 25l to end it, which I think is turning the cursor on
> and off (based on https://en.wikipedia.org/wiki/ANSI_escape_code).  I
> apparently fixed this previously by building wine with
> --without-curses
> (https://www.mail-archive.com/gcc@gcc.gnu.org/msg86366.html), but that
> option to wine was removed.  Is there a way to hack this on the Deja
> side to ignore the escapes?  Or to tell it to run in a way that makes
> wine not emit them?

Truth is, I don't know.

I have included the gcc mailing list in this reply, where more
knowledgeable people can be found :-)

Re: testsuite under wine

[NightStrike]

On Sat, Dec 17, 2022 at 5:52 AM Thomas Koenig <tkoenig@netcologne.de> wrote:
>
> On 17.12.22 01:26, NightStrike wrote:
> > On Fri, Dec 16, 2022 at 1:44 AM Thomas Koenig <tkoenig@netcologne.de> wrote:
> >>
> >> On 16.12.22 03:20, NightStrike via Fortran wrote:
> >>
> >>> When I run the testsuite under wine, I'm getting a lot of ANSI escape
> >>> sequences.  We had fixed this long ago, but it seems to be back.  Any
> >>> idea what I should change in my configuration to have this not happen?
> >>
> >> This should probably be fixed properly in some *.exp file, but you can
> >> try setting the GCC_COLORS environment variable to an empty string
> >> before running the test.
> >
> > That didn't help.  It looks like this is always escape 25h to start
> > the output and 25l to end it, which I think is turning the cursor on
> > and off (based on https://en.wikipedia.org/wiki/ANSI_escape_code).  I
> > apparently fixed this previously by building wine with
> > --without-curses
> > (https://www.mail-archive.com/gcc@gcc.gnu.org/msg86366.html), but that
> > option to wine was removed.  Is there a way to hack this on the Deja
> > side to ignore the escapes?  Or to tell it to run in a way that makes
> > wine not emit them?
>
> Truth is, I don't know.
>
> I have included the gcc mailing list in this reply, where more
> knowledgeable people can be found :-)

Thanks.  I'm including the dejagnu list, maybe someone there can help, too.

For clarity, this is an example of what I see:

Output was:
^[[mM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[
?25h^[[?25l8^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M
^[[?25lM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1
^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M
^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[
[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M
^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[
[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M
^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[
[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M
^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[
[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M
^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[
[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M
^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[
[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M
^M^M

Should match:
My_R1    : 78 56 34 12.*
My_R2    : 12 34 56 78.*
Local_R1 : 78 56 34 12.*
Local_R2 : 12 34 56 78.*
Local_R1 : 78 56 34 12.*
Local_R2 : 12 34 56 78.*
Local_R1 : 78 56 34 12.*
Local_R2 : 12 34 56 78.*

Re: testsuite under wine

[Jacob Bachmeyer]

NightStrike wrote:
> On Sat, Dec 17, 2022 at 5:52 AM Thomas Koenig <tkoenig@netcologne.de> wrote:
>   
>> On 17.12.22 01:26, NightStrike wrote:
>>     
>>> On Fri, Dec 16, 2022 at 1:44 AM Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>       
>>>> On 16.12.22 03:20, NightStrike via Fortran wrote:
>>>>
>>>>         
>>>>> When I run the testsuite under wine, I'm getting a lot of ANSI escape
>>>>> sequences.  We had fixed this long ago, but it seems to be back.  Any
>>>>> idea what I should change in my configuration to have this not happen?
>>>>>           
>>>> This should probably be fixed properly in some *.exp file, but you can
>>>> try setting the GCC_COLORS environment variable to an empty string
>>>> before running the test.
>>>>         
>>> That didn't help.  It looks like this is always escape 25h to start
>>> the output and 25l to end it, which I think is turning the cursor on
>>> and off (based on https://en.wikipedia.org/wiki/ANSI_escape_code).  I
>>> apparently fixed this previously by building wine with
>>> --without-curses
>>> (https://www.mail-archive.com/gcc@gcc.gnu.org/msg86366.html), but that
>>> option to wine was removed.  Is there a way to hack this on the Deja
>>> side to ignore the escapes?  Or to tell it to run in a way that makes
>>> wine not emit them?
>>>       
>> Truth is, I don't know.
>>
>> I have included the gcc mailing list in this reply, where more
>> knowledgeable people can be found :-)
>>     
>
> Thanks.  I'm including the dejagnu list, maybe someone there can help, too.
>
> For clarity, this is an example of what I see:
>
> Output was:
> ^[[mM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[
> ?25h^[[?25l8^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M
> ^[[?25lM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1
> ^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M
> ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[
> [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M
> ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[
> [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M
> ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[
> [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M
> ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[
> [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M
> ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[
> [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M
> ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[
> [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M
> ^M^M
>
> Should match:
> My_R1    : 78 56 34 12.*
> My_R2    : 12 34 56 78.*
> Local_R1 : 78 56 34 12.*
> Local_R2 : 12 34 56 78.*
> Local_R1 : 78 56 34 12.*
> Local_R2 : 12 34 56 78.*
> Local_R1 : 78 56 34 12.*
> Local_R2 : 12 34 56 78.*
>   

DejaGnu cannot routinely strip escape sequences because they could be 
part of the intended output---or strictly forbidden in the intended 
output.  Further, I suspect that the comparison is being carried out in 
the testsuite code rather than the framework, but the thread that 
arrived on the DejaGnu list does not mention what test is failing or 
what testsuite is being run.  Based on the inclusion of 
fortran@gcc.gnu.org, I am guessing this is an issue with the GNU Fortran 
tests.

This is either a testsuite problem or an environment problem.  The GNU 
Fortran I/O module certainly has interesting behavior here.  Try setting 
TERM=dumb in the environment while running the testsuite.  If that fixes 
the problem, it may be appropriate to add "set ::env(TERM) dumb" to the 
tool init file for GNU Fortran.


-- Jacob

Re: testsuite under wine

[NightStrike]

On Sat, Dec 17, 2022 at 10:44 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>
> NightStrike wrote:
> > On Sat, Dec 17, 2022 at 5:52 AM Thomas Koenig <tkoenig@netcologne.de> wrote:
> >
> >> On 17.12.22 01:26, NightStrike wrote:
> >>
> >>> On Fri, Dec 16, 2022 at 1:44 AM Thomas Koenig <tkoenig@netcologne.de> wrote:
> >>>
> >>>> On 16.12.22 03:20, NightStrike via Fortran wrote:
> >>>>
> >>>>
> >>>>> When I run the testsuite under wine, I'm getting a lot of ANSI escape
> >>>>> sequences.  We had fixed this long ago, but it seems to be back.  Any
> >>>>> idea what I should change in my configuration to have this not happen?
> >>>>>
> >>>> This should probably be fixed properly in some *.exp file, but you can
> >>>> try setting the GCC_COLORS environment variable to an empty string
> >>>> before running the test.
> >>>>
> >>> That didn't help.  It looks like this is always escape 25h to start
> >>> the output and 25l to end it, which I think is turning the cursor on
> >>> and off (based on https://en.wikipedia.org/wiki/ANSI_escape_code).  I
> >>> apparently fixed this previously by building wine with
> >>> --without-curses
> >>> (https://www.mail-archive.com/gcc@gcc.gnu.org/msg86366.html), but that
> >>> option to wine was removed.  Is there a way to hack this on the Deja
> >>> side to ignore the escapes?  Or to tell it to run in a way that makes
> >>> wine not emit them?
> >>>
> >> Truth is, I don't know.
> >>
> >> I have included the gcc mailing list in this reply, where more
> >> knowledgeable people can be found :-)
> >>
> >
> > Thanks.  I'm including the dejagnu list, maybe someone there can help, too.
> >
> > For clarity, this is an example of what I see:
> >
> > Output was:
> > ^[[mM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[
> > ?25h^[[?25l8^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M
> > ^[[?25lM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1
> > ^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M
> > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[
> > [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M
> > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[
> > [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M
> > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[
> > [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M
> > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[
> > [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M
> > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[
> > [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M
> > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[
> > [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M
> > ^M^M
> >
> > Should match:
> > My_R1    : 78 56 34 12.*
> > My_R2    : 12 34 56 78.*
> > Local_R1 : 78 56 34 12.*
> > Local_R2 : 12 34 56 78.*
> > Local_R1 : 78 56 34 12.*
> > Local_R2 : 12 34 56 78.*
> > Local_R1 : 78 56 34 12.*
> > Local_R2 : 12 34 56 78.*
> >
>
> DejaGnu cannot routinely strip escape sequences because they could be
> part of the intended output---or strictly forbidden in the intended
> output.  Further, I suspect that the comparison is being carried out in
> the testsuite code rather than the framework, but the thread that
> arrived on the DejaGnu list does not mention what test is failing or
> what testsuite is being run.  Based on the inclusion of
> fortran@gcc.gnu.org, I am guessing this is an issue with the GNU Fortran
> tests.

Every GCC language testsuite has these failures, I just singled out
Fortran because I was interested in it.

> This is either a testsuite problem or an environment problem.  The GNU
> Fortran I/O module certainly has interesting behavior here.  Try setting
> TERM=dumb in the environment while running the testsuite.  If that fixes
> the problem, it may be appropriate to add "set ::env(TERM) dumb" to the
> tool init file for GNU Fortran.

Setting TERM doesn't help.  Wine tries to emulate the windows console,
which requires outputting this stuff.  It does so any time there's a
pty, and I believe that Deja creates a pty when running the tests.
Wine people suggested if I could somehow run the test as "wine ./a.exe
| cat", that it would prevent this behavior, but I couldn't find a way
to do that.  For now, I modified Wine to kludge out the code that
creates the console, and a long term solution needs to be on the Wine
side.  I was just hoping for a less dirty hack from the Deja side.

Note that there are other problems, too.  It seems that when Deja is
matching against "\n", it doesn't handle the different line endings of
Windows correctly in a cross environment.  Is there a way that I can
set how to interpret \n in a target-board file?  This affects fortran
and other language tests also.

Re: testsuite under wine

[Jacob Bachmeyer]

NightStrike wrote:
> On Sat, Dec 17, 2022 at 10:44 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>   
>> [...]
>> This is either a testsuite problem or an environment problem.  The GNU
>> Fortran I/O module certainly has interesting behavior here.  Try setting
>> TERM=dumb in the environment while running the testsuite.  If that fixes
>> the problem, it may be appropriate to add "set ::env(TERM) dumb" to the
>> tool init file for GNU Fortran.
>>     
>
> Setting TERM doesn't help.  Wine tries to emulate the windows console,
> which requires outputting this stuff.  It does so any time there's a
> pty, and I believe that Deja creates a pty when running the tests.
>   

That is a bug in Wine:  the escapes should be suppressed entirely if the 
terminal does not support them---and the "dumb" terminal does not 
support them.

> Wine people suggested if I could somehow run the test as "wine ./a.exe
> | cat", that it would prevent this behavior, but I couldn't find a way
> to do that.

Actually... I think you can, as long as the programs to be run do not 
require input, but you will need to modify the testsuite to spawn 
programs differently when using Wine.  There is probably a "spawn" 
command somewhere in the testsuite.  You will want to change that to add 
a conditional for cross-testing using Wine and to use a pipeline in that 
case.  Something like:

8<------
if { ![isnative] && ![isremote target] && [istarget *-*-mingw*] } { # or similar pattern
    spawn -open [open "| wine ${command} </dev/null" r]
} else {
    # the original "spawn" command
    spawn $command
}
8<------


If these are "dg" tests, the code you need to change should be in the 
${tool}_load procedure in the tool init file, most likely in 
testsuite/lib.  Again, this can work only if the test programs are 
non-interactive, since Tcl does not allow running a subprocess with both 
input and output on pipes connected to the main program.  (Expect does, 
but uses a pty instead of a pair of pipes to accomplish this.)  The 
above example connects the child process's stdin to /dev/null and its 
stdout to a pipe to the Tcl interpreter running the testsuite; Expect 
then wraps the file handle in an Expect spawn handle and the rest of the 
code can use the 'expect' command as normal to read its output.

Also, "wine" should probably be instead a global variable WINE that can 
be set to a specific Wine executable if needed, but the best long-term 
solution is probably to fix the console emulation in Wine.

There may be more layers of indirection involved, possibly back into the 
framework; I am somewhat less familiar with the details of the GCC 
testsuite, so it would be very helpful if you could point me to one of 
the tests in question.  This may turn into a feature request for general 
framework support for emulated targets using "interposition emulators" 
such as Wine or QEMU.  I will think about that, but it probably will not 
be in 1.6.4.

>   For now, I modified Wine to kludge out the code that
> creates the console, and a long term solution needs to be on the Wine
> side.  I was just hoping for a less dirty hack from the Deja side.
>   

I think that the long-term solution is that Wine should properly honor 
the TERM environment variable and not produce escape codes that the 
declared terminal does not support.

> Note that there are other problems, too.  It seems that when Deja is
> matching against "\n", it doesn't handle the different line endings of
> Windows correctly in a cross environment.  Is there a way that I can
> set how to interpret \n in a target-board file?  This affects fortran
> and other language tests also.

No---problems related to line endings are bugs in the testsuite.  This 
caveat is documented in *Note: (dejagnu)Writing a test case.  The manual 
explains:  "Note that terminal settings may result in the insertion of 
additional `\r' characters, usually translating `\n' to `\r\n'."

At the terminal layer, POSIX can *also* use "\r\n" sequences, since some 
terminals historically needed them, even though the standard line ending 
*within* a POSIX system is "\n" by itself.  Because a pty simply 
presents the "terminal" side of the interface to the controlling 
program, Expect can receive "\r\n" when the subprocess emits "\n"; the 
translation is performed by the kernel terminal driver and DejaGnu 
testsuites must be prepared to receive (and discard) excess carriage 
returns in the general case.


-- Jacob

RE: testsuite under wine

[Torbjorn SVENSSON]

Hi,

> -----Original Message-----
> From: dejagnu-bounces+torbjorn.svensson=st.com@gnu.org <dejagnu-
> bounces+torbjorn.svensson=st.com@gnu.org> On Behalf Of Jacob Bachmeyer
> Sent: den 19 december 2022 05:29
> To: NightStrike <nightstrike@gmail.com>
> Cc: Thomas Koenig <tkoenig@netcologne.de>; fortran@gcc.gnu.org; gcc
> mailing list <gcc@gcc.gnu.org>; dejagnu@gnu.org
> Subject: Re: testsuite under wine
> 
> NightStrike wrote:
> > On Sat, Dec 17, 2022 at 10:44 PM Jacob Bachmeyer
> <jcb62281@gmail.com> wrote:
> >
> >> [...]
> >> This is either a testsuite problem or an environment problem.  The GNU
> >> Fortran I/O module certainly has interesting behavior here.  Try setting
> >> TERM=dumb in the environment while running the testsuite.  If that fixes
> >> the problem, it may be appropriate to add "set ::env(TERM) dumb" to the
> >> tool init file for GNU Fortran.
> >>
> >
> > Setting TERM doesn't help.  Wine tries to emulate the windows console,
> > which requires outputting this stuff.  It does so any time there's a
> > pty, and I believe that Deja creates a pty when running the tests.
> >
> 
> That is a bug in Wine:  the escapes should be suppressed entirely if the
> terminal does not support them---and the "dumb" terminal does not
> support them.

I'm not sure if this helps anyone, but I experienced something similar with Cygwin a while back.
What I had to do in order to have expect working when testing GCC on Windows 10 was to defined the "CYGWIN" environment variable to "disable_pcon" (https://cygwin.com/cygwin-ug-net/using-cygwinenv.html). If I did not define this variable, then Cygwin would inject an escape sequence that would make all pattern checks fail on the output.

I don't know if Cygwin might has changed this behavior, but it was an issue in the past anyway.

Kind regards,
Torbjörn

Re: testsuite under wine

[NightStrike]

On Mon, Dec 19, 2022 at 5:43 AM Torbjorn SVENSSON
<torbjorn.svensson@st.com> wrote:
> I'm not sure if this helps anyone, but I experienced something similar with Cygwin a while back.
> What I had to do in order to have expect working when testing GCC on Windows 10 was to defined the "CYGWIN" environment variable to "disable_pcon" (https://cygwin.com/cygwin-ug-net/using-cygwinenv.html). If I did not define this variable, then Cygwin would inject an escape sequence that would make all pattern checks fail on the output.
>
> I don't know if Cygwin might has changed this behavior, but it was an issue in the past anyway.

This is extremely helpful for when I start testing natively, thank
you.  I think in general the problem is the same, but Wine doesn't
immediately have a comparable workaround.

Re: testsuite under wine

[NightStrike]

On Sun, Dec 18, 2022 at 11:29 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>
> NightStrike wrote:
> > On Sat, Dec 17, 2022 at 10:44 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
> >
> >> [...]
> >> This is either a testsuite problem or an environment problem.  The GNU
> >> Fortran I/O module certainly has interesting behavior here.  Try setting
> >> TERM=dumb in the environment while running the testsuite.  If that fixes
> >> the problem, it may be appropriate to add "set ::env(TERM) dumb" to the
> >> tool init file for GNU Fortran.
> >>
> >
> > Setting TERM doesn't help.  Wine tries to emulate the windows console,
> > which requires outputting this stuff.  It does so any time there's a
> > pty, and I believe that Deja creates a pty when running the tests.
> >
>
> That is a bug in Wine:  the escapes should be suppressed entirely if the
> terminal does not support them---and the "dumb" terminal does not
> support them.

I think it's a paradigm difference.  I'm just guessing here, but Wine
runs in a terminal that doesn't know about TERM.  It's mimicking the
"cmd.exe" that you'd run on a native Windows system (I think... I'd
welcome corrections from those more knowledgeable).  In theory, the
effect would be the same if I set up a remote target board to ssh to a
windows system and get dropped into a cmd.exe shell (I used to run
this way... it'd take about a week to run the whole testsuite. It
sucked...)


[...snip for now, I'm working on getting reasonable output back to
you, including an example of a case that fails, and how it responds to
your suggestion. Stay tuned...]


> >   For now, I modified Wine to kludge out the code that
> > creates the console, and a long term solution needs to be on the Wine
> > side.  I was just hoping for a less dirty hack from the Deja side.
> >
>
> I think that the long-term solution is that Wine should properly honor
> the TERM environment variable and not produce escape codes that the
> declared terminal does not support.

Agreed, just trying to get by for now.

> > Note that there are other problems, too.  It seems that when Deja is
> > matching against "\n", it doesn't handle the different line endings of
> > Windows correctly in a cross environment.  Is there a way that I can
> > set how to interpret \n in a target-board file?  This affects fortran
> > and other language tests also.
>
> No---problems related to line endings are bugs in the testsuite.  This
> caveat is documented in *Note: (dejagnu)Writing a test case.  The manual
> explains:  "Note that terminal settings may result in the insertion of
> additional `\r' characters, usually translating `\n' to `\r\n'."
>
> At the terminal layer, POSIX can *also* use "\r\n" sequences, since some
> terminals historically needed them, even though the standard line ending
> *within* a POSIX system is "\n" by itself.  Because a pty simply
> presents the "terminal" side of the interface to the controlling
> program, Expect can receive "\r\n" when the subprocess emits "\n"; the
> translation is performed by the kernel terminal driver and DejaGnu
> testsuites must be prepared to receive (and discard) excess carriage
> returns in the general case.

Here's one that tries to handle different line endings (most tests do
not do this):

gfortran.dg/parameter_array_dummy.f90

which uses:
! { dg-output " *1 aa(\n|\r\n|\r)" }
! { dg-output " *2 ab(\n|\r\n|\r)" }
! { dg-output " *3 aaab(\n|\r\n|\r)" }
! { dg-output " *4 abaa(\n|\r\n|\r)" }
! { dg-output " *5 ababab(\n|\r\n|\r)" }

But this results in:

FAIL: gfortran.dg/parameter_array_dummy.f90   -O0  output pattern test
Output was:
           1 aa^M^M
           2 ab^M^M
           3 aaab^M^M
           4 abaa^M^M
           5 ababab^M^M

Should match:
 *1 aa(
|^M
|^M) *2 ab(
|^M
|^M) *3 aaab(
|^M
|^M) *4 abaa(
|^M
|^M) *5 ababab(
|^M
|^M)


The problem being that we are getting "0x0d 0x0d 0x0a", or \r\r\n.
(Other examples fail differently, for instance there's a Rust test
that outputs \r\r\n\n... but let's start with this one).

Re: testsuite under wine

[Jacob Bachmeyer]

NightStrike wrote:
> On Sun, Dec 18, 2022 at 11:29 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>   
>> NightStrike wrote:
>>     
>>> On Sat, Dec 17, 2022 at 10:44 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>>>
>>>       
>>>> [...]
>>>> This is either a testsuite problem or an environment problem.  The GNU
>>>> Fortran I/O module certainly has interesting behavior here.  Try setting
>>>> TERM=dumb in the environment while running the testsuite.  If that fixes
>>>> the problem, it may be appropriate to add "set ::env(TERM) dumb" to the
>>>> tool init file for GNU Fortran.
>>>>
>>>>         
>>> Setting TERM doesn't help.  Wine tries to emulate the windows console,
>>> which requires outputting this stuff.  It does so any time there's a
>>> pty, and I believe that Deja creates a pty when running the tests.
>>>
>>>       
>> That is a bug in Wine:  the escapes should be suppressed entirely if the
>> terminal does not support them---and the "dumb" terminal does not
>> support them.
>>     
>
> I think it's a paradigm difference.  I'm just guessing here, but Wine
> runs in a terminal that doesn't know about TERM.

Terminals never know about TERM.  TERM exists to inform programs what 
terminal type they are running with.  X11 terminal emulators *set* TERM 
in the environment given to their child processes to identify themselves 
for this reason.

> It's mimicking the "cmd.exe" that you'd run on a native Windows system (I think... I'd welcome corrections from those more knowledgeable).

Yes, but Wine must emulate a console window with the terminal that it 
has, which is not necessarily a VT100-alike, therefore it should be 
checking the TERM variable at the minimum, and preferably using terminfo 
to adapt whatever escape sequences the terminal in use actually expects, 
or gracefully degrade when the terminal simply does not support the 
needed features.

(Minor technical note:  while cmd.exe is a console program, it does not 
actually provide the console; that is a different part of the NT system, 
but I am not certain exactly what.  Wine is trying to emulate the 
Windows console, not cmd.exe.)

> In theory, the effect would be the same if I set up a remote target board to ssh to a windows system and get dropped into a cmd.exe shell (I used to run this way... it'd take about a week to run the whole testsuite. It sucked...)
>   

Ah yes, Windows has some serious performance problems related to 
spawning processes.  :-D  I once cross-compiled GNU libc from a Windows 
(98SE) host while setting up my first GNU/Linux system.  It took about 
three days and the machine needed a universal Windows fix-it (reboot) 
afterwards due to memory leaks resulting in swap thrashing that 
continued even after all application programs had been closed---just a 
desktop, disk light on almost solidly, mouse pointer lagging mouse 
movement visibly.  Later, on the same hardware but using a Linux kernel, 
rebuilding glibc took the expected two hours.  Also, the same hardware 
semi-regularly locked up solid (even the mouse pointer would not move) 
with Windows... and not even once with GNU/Linux/XFree86.  [...snip 
extended rant...]

> [...]
>>> Note that there are other problems, too.  It seems that when Deja is
>>> matching against "\n", it doesn't handle the different line endings of
>>> Windows correctly in a cross environment.  Is there a way that I can
>>> set how to interpret \n in a target-board file?  This affects fortran
>>> and other language tests also.
>>>       
>> No---problems related to line endings are bugs in the testsuite.  This
>> caveat is documented in *Note: (dejagnu)Writing a test case.  The manual
>> explains:  "Note that terminal settings may result in the insertion of
>> additional `\r' characters, usually translating `\n' to `\r\n'."
>>
>> At the terminal layer, POSIX can *also* use "\r\n" sequences, since some
>> terminals historically needed them, even though the standard line ending
>> *within* a POSIX system is "\n" by itself.  Because a pty simply
>> presents the "terminal" side of the interface to the controlling
>> program, Expect can receive "\r\n" when the subprocess emits "\n"; the
>> translation is performed by the kernel terminal driver and DejaGnu
>> testsuites must be prepared to receive (and discard) excess carriage
>> returns in the general case.
>>     
>
> Here's one that tries to handle different line endings (most tests do
> not do this):
>
> gfortran.dg/parameter_array_dummy.f90
>
> which uses:
> ! { dg-output " *1 aa(\n|\r\n|\r)" }
> ! { dg-output " *2 ab(\n|\r\n|\r)" }
> ! { dg-output " *3 aaab(\n|\r\n|\r)" }
> ! { dg-output " *4 abaa(\n|\r\n|\r)" }
> ! { dg-output " *5 ababab(\n|\r\n|\r)" }
>
> But this results in:
>
> FAIL: gfortran.dg/parameter_array_dummy.f90   -O0  output pattern test
> [...]
>
> The problem being that we are getting "0x0d 0x0d 0x0a", or \r\r\n.
>   

These are testsuite bugs.

This detail also (finally) tells me that the framework /is/ involved 
here after all, so there are possibilities for enhancing lib/dg.exp to 
reduce these issues.  One possibility could be to use "$" in dg-output 
patterns as an end-of-line marker, internally substituted with a known 
EOL pattern for the platform being tested.  (Not yet implemented, and 
testsuites using it would not be able to run with older framework 
versions.)  Another solution is to note that dg-output matching does 
*not* use Expect and is actually batch-oriented:  the test program is 
run (and its output gathered) using ${tool}_load, and then the patterns 
are matched against that returned output.  This means that the Expect 
caveats described in the manual for normal tests do not apply here, and 
a simple EOL subpattern is usable:  "[\r\n]+" (using that subpattern 
with Expect *will* cause subtle timing-related bugs)

> (Other examples fail differently, for instance there's a Rust test
> that outputs \r\r\n\n... but let's start with this one).
>   

I believe that dg-output could reliably match that with an "[\r\n]+" 
subpattern, too.  :-)

One last detail that might help you:  ${tool}_load has a chance to apply 
regsub(n) to the output before returning it.  If the testsuite should 
ignore escape sequences, and you can match them with a Tcl regexp, you 
could use a similar conditional as my previous suggestion to prune the 
output before dg.exp examines it.


-- Jacob

Re: testsuite under wine

[NightStrike]

On Wed, Dec 21, 2022 at 12:38 PM Jacek Caban <jacek@codeweavers.com> wrote:
>
> Hi all,
>
>
> I'm responsible for Wine changes that cause your problems. I'm also
> CCing Eric, who is Wine console expert, maybe he has better ideas. Eric,
> see [1] if you're interested in the context.
>
>
> Recent Wine versions implement Windows pseudo-consoles, see [2] for a
> bit more details. It's generally Microsoft's semi-recent API that's
> intended to be more compatible with POSIX than what was present in
> previous versions of Windows. In theory, with that implemented, we could
> just plug tty fds that we get from Unix and have Unix consoles working
> using those Windows APIs. In practice, it's not quite as good as
> promised and we need some tweaks to make it work nicely. We could
> improve those tweaks, but there are architectural limitations that will
> come to play sooner or later.
>
>
>  > I think that the long-term solution is that Wine should properly honor
>  > the TERM environment variable and not produce escape codes that the
>  > declared terminal does not support.
>
>
> 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. I'm not really familiar with DejaGnu, but if you want to
> match application output, that's probably not what you're looking for.
>
>
> The reason the previous workaround of compiling Wine without ncurses
> worked is that if made Wine treat tty stdin/stdout in a way very similar
> to regular pipes, so no extra processing was performed. This was more of
> a side effect than a design choice. It should be possible to provide
> some way to achieve that with the new Wine architecture. I'm attaching
> an example of Wine patch that would allow it. With that patch, you may
> disable conhost.exe (via winecfg or WINEDLLOVERRIDES=conhost.exe=d
> environment variable) and achieve something similar to previous workaround.
>
>
> Long term, I think that it would be best to get rid of console behaviour
> expectations by using Windows build of DejaGnu. My understanding is that
> it requires Cygwin, so the stack would be: Windows DejaGnu on Cygwin on
> Wine on Linux. This would make all similar mismatches in expectations
> non-existent. Cygwin is tricky to run on Wine, there are a few known
> problems like [3], but we're getting there.
>
>
> Jacek
>
>
> [1] https://gcc.gnu.org/pipermail/fortran/2022-December/058645.html
>
> [2]
> https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/
>
> [3] https://bugs.winehq.org/show_bug.cgi?id=47808

First, a big giant thank you for this patch.  I confirmed that I can
use this to replace the "return immediately from init_console" hack,
and it applies cleanly to 7.20.

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.

Re: testsuite under wine

[Jacob Bachmeyer]

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.)


-- Jacob

Re: testsuite under wine

[NightStrike]

On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> 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.

Rust is getting \r\r\n\n (as opposed to \r\n\r\n), so...  yeah.  Could
be the rust test, could be the rust frontend, could be another weird
Wine interaction.

Re: testsuite under wine

[Eric Pouech]

Le 23/12/2022 à 11:36, NightStrike a écrit :
> On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> 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

Re: testsuite under wine

[Jacob Bachmeyer]

NightStrike wrote:
> On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> 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 close, and yet so far...  script(1) /also/ uses a pty, so it is 
getting the same translations as Expect and therefore DejaGnu.

> 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.
>   

I doubt that Wine is doing that translation.  MinGW libc produces output 
conformant to Windows conventions, so printf("\n") on a text handle 
emits "\r\n", which Wine passes along.  POSIX convention is that "\n" is 
translated to "\r\n" in the kernel terminal driver upon output, so the 
kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding 
"\r\r\n" at the pty master end.  This is why DejaGnu testsuites must be 
prepared to discard excess carriage returns.  The first CR came from 
MinGW libc; the second CR came from the kernel terminal driver; the LF 
was ultimately passed through.

> Rust is getting \r\r\n\n (as opposed to \r\n\r\n), so...  yeah.  Could
> be the rust test, could be the rust frontend, could be another weird
> Wine interaction.
>   

That is probably either a Rust bug or the intended behavior.  Does the 
test produce "\n\n" or "\r\n\n" when run natively?  (Note that the 
terminal driver could reasonably optimize:  once one CR has been 
produced, any number of LF may follow:  the cursor is assumed to remain 
at the left edge.  It is possible that the kernel terminal driver could 
even strip the second CR in "\r\n\r\n" since its only effect on an 
actual serial terminal would be wasting transmission time.)


-- Jacob

Re: testsuite under wine

[Mark Wielaard]

Hi,

On Fri, Dec 23, 2022 at 10:00:36PM -0600, Jacob Bachmeyer via Gcc wrote:
> NightStrike wrote:
> > Rust is getting \r\r\n\n (as opposed to \r\n\r\n), so...  yeah.  Could
> > be the rust test, could be the rust frontend, could be another weird
> > Wine interaction.
> 
> That is probably either a Rust bug or the intended behavior.

Note that in rust a string tokens or doc comments with an "Isolated
CR" (a \r not immediately followed by an \n) is an error and the
testsuite contains a couple of tests to make sure the compiler detects
that. Which might cause even more confusion.

Cheers,

Mark

Re: testsuite under wine

[NightStrike]

On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
> NightStrike wrote:
> > On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> 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 close, and yet so far...  script(1) /also/ uses a pty, so it is
> getting the same translations as Expect and therefore DejaGnu.
>
> > 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.
> >
>
> I doubt that Wine is doing that translation.  MinGW libc produces output
> conformant to Windows conventions, so printf("\n") on a text handle
> emits "\r\n", which Wine passes along.  POSIX convention is that "\n" is
> translated to "\r\n" in the kernel terminal driver upon output, so the
> kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding
> "\r\r\n" at the pty master end.  This is why DejaGnu testsuites must be
> prepared to discard excess carriage returns.  The first CR came from
> MinGW libc; the second CR came from the kernel terminal driver; the LF
> was ultimately passed through.

Jacek and I have been digging into this on IRC, and he's been very
helpful in trying to get further, but we're still stuck.  We tried to
be more introspective, inserting strace both as "strace script wine"
and as "script strace wine".  We tried running just "wine a.exe"
without any extra glue, and logging the raw SSH packets from putty.
After many iterations on these and other tests, Jacek finally had the
idea to try removing Windows entirely from the equation, and we ran
with a purely unix program / compiler combination:

#include <unistd.h>

int main()
{
        write(1, "test\r\n", 6);
        return 0;
}

(and also as "test\n", 5)

In both versions, the following was observed:

case 1) ./a.out | xxd
case 2) script -c ./a.out out; xxd out
case 3) enable putting logging, ./a.out

In case 1, xxd showed no extra \r's.  In cases 2 and 3, there was an
extra \r (either 0d 0d 0a for test\r\n, or 0d 0a for test\n).

So, is it possible after all of this back and forth regarding mingw,
wine, and others, that it's down to the write() system call that's
inserting extra \r's?  Is this expected?

Re: testsuite under wine

[Jacob Bachmeyer]

NightStrike wrote:
> On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>   
>> NightStrike wrote:
>>     
>>> On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>>>       
>>>> [...]
>>> 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.
>>>
>>>       
>> I doubt that Wine is doing that translation.  MinGW libc produces output
>> conformant to Windows conventions, so printf("\n") on a text handle
>> emits "\r\n", which Wine passes along.  POSIX convention is that "\n" is
>> translated to "\r\n" in the kernel terminal driver upon output, so the
>> kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding
>> "\r\r\n" at the pty master end.  This is why DejaGnu testsuites must be
>> prepared to discard excess carriage returns.  The first CR came from
>> MinGW libc; the second CR came from the kernel terminal driver; the LF
>> was ultimately passed through.
>>     
>
> Jacek and I have been digging into this on IRC, and he's been very
> helpful in trying to get further, but we're still stuck.  We tried to
> be more introspective, inserting strace both as "strace script wine"
> and as "script strace wine".  We tried running just "wine a.exe"
> without any extra glue, and logging the raw SSH packets from putty.
> After many iterations on these and other tests, Jacek finally had the
> idea to try removing Windows entirely from the equation, and we ran
> with a purely unix program / compiler combination:
>
> #include <unistd.h>
>
> int main()
> {
>         write(1, "test\r\n", 6);
>         return 0;
> }
>
> (and also as "test\n", 5)
>
> In both versions, the following was observed:
>
> case 1) ./a.out | xxd
> case 2) script -c ./a.out out; xxd out
> case 3) enable putting logging, ./a.out
>
> In case 1, xxd showed no extra \r's.  In cases 2 and 3, there was an
> extra \r (either 0d 0d 0a for test\r\n, or 0d 0a for test\n).
>
> So, is it possible after all of this back and forth regarding mingw,
> wine, and others, that it's down to the write() system call that's
> inserting extra \r's?  Is this expected?
>   

"This is why DejaGnu testsuites must be prepared to discard excess 
carriage returns."

The write(2) system call inserts nothing and simply hands off the buffer 
to the relevant part of the kernel I/O subsystem.  (The kernel in POSIX 
is *not* a monolithic black box.)  When stdout for your test program is 
a pty slave, that relevant part is the kernel terminal driver.  The 
kernel terminal driver is converting "\n" to "\r\n" upon output to the 
associated port, since hardware terminals typically *do* require CRLF.  
The associated port in this case is virtual and part of the kernel pty 
subsystem, which presents octets written to that port to its associated 
pty master device.  The user-visible pty slave device acts just like a 
serial terminal, including all translations normally done for handling 
serial terminals.

A pty is conceptually a null-modem cable connected between two 
infinitely-fast serial ports on the same machine, although the slave 
will still report an actual baud rate if queried.  (Run "stty" with no 
arguments under script(1), an ssh session, or an X11 terminal emulator 
to see what a pty slave looks like on your machine.)

In your case 1, the pty subsystem is not used and output is collected 
over a pipe.  Using "./a.out > out; xxd out" would produce the same 
results.  In cases 2 and 3, there is a pty involved, either set up by 
script(1) or by sshd (assuming you meant "enable putty logging" in case 
3) that performs the standard terminal translations.  In all cases, 
strace(1) will show the exact string written to the pty slave device, 
which will not include any extra CRs because *those* *are* *inserted* 
*by* *the* *kernel* *terminal* *driver* as the data is transferred to 
the pty master device's read queue.

This insertion of carriage returns is expected and standardized behavior 
in POSIX and is the reason Unix could use bare LF as end-of-line even 
though hardware terminals always needed CRLF.  CP/M (and therefore 
MS-DOS which began its existence as a cheap CP/M knockoff) did not have 
this translation layer and instead dumped the complexity of a two-octet 
end-of-line sequence on user programs, leading to much confusion even 
today.  This is not a Wine issue, although the terminal escape sequences 
in your original issue *were* from Wine.  Note that the number of excess 
carriage returns that a DejaGnu testsuite must be prepared to discard is 
unspecified because running tests on remote targets may result in *any* 
*number* of CRs preceding each LF by the time the results reach the test 
driver machine in more complex testing lab environments.


-- Jacob

Re: testsuite under wine

[Jerry D]

On 1/5/23 7:33 PM, Jacob Bachmeyer via Fortran wrote:
> NightStrike wrote:
>> On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer <jcb62281@gmail.com> 
>> wrote:
>>> NightStrike wrote:
>>>> On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer 
>>>> <jcb62281@gmail.com> wrote:
>>>>> [...]
>>>> 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.
>>>>
>>> I doubt that Wine is doing that translation.  MinGW libc produces output
>>> conformant to Windows conventions, so printf("\n") on a text handle
>>> emits "\r\n", which Wine passes along.  POSIX convention is that "\n" is
>>> translated to "\r\n" in the kernel terminal driver upon output, so the
>>> kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding
>>> "\r\r\n" at the pty master end.  This is why DejaGnu testsuites must be
>>> prepared to discard excess carriage returns.  The first CR came from
>>> MinGW libc; the second CR came from the kernel terminal driver; the LF
>>> was ultimately passed through.
>>
>> Jacek and I have been digging into this on IRC, and he's been very
>> helpful in trying to get further, but we're still stuck.  We tried to
>> be more introspective, inserting strace both as "strace script wine"
>> and as "script strace wine".  We tried running just "wine a.exe"
>> without any extra glue, and logging the raw SSH packets from putty.
>> After many iterations on these and other tests, Jacek finally had the
>> idea to try removing Windows entirely from the equation, and we ran
>> with a purely unix program / compiler combination:
>>
>> #include <unistd.h>
>>
>> int main()
>> {
>>         write(1, "test\r\n", 6);
>>         return 0;
>> }
>>
>> (and also as "test\n", 5)
>>
>> In both versions, the following was observed:
>>
>> case 1) ./a.out | xxd
>> case 2) script -c ./a.out out; xxd out
>> case 3) enable putting logging, ./a.out
>>
>> In case 1, xxd showed no extra \r's.  In cases 2 and 3, there was an
>> extra \r (either 0d 0d 0a for test\r\n, or 0d 0a for test\n).
>>
>> So, is it possible after all of this back and forth regarding mingw,
>> wine, and others, that it's down to the write() system call that's
>> inserting extra \r's?  Is this expected?
> 
> "This is why DejaGnu testsuites must be prepared to discard excess 
> carriage returns."
> 
> The write(2) system call inserts nothing and simply hands off the buffer 
> to the relevant part of the kernel I/O subsystem.  (The kernel in POSIX 
> is *not* a monolithic black box.)  When stdout for your test program is 
> a pty slave, that relevant part is the kernel terminal driver.  The 
> kernel terminal driver is converting "\n" to "\r\n" upon output to the 
> associated port, since hardware terminals typically *do* require CRLF. 
> The associated port in this case is virtual and part of the kernel pty 
> subsystem, which presents octets written to that port to its associated 
> pty master device.  The user-visible pty slave device acts just like a 
> serial terminal, including all translations normally done for handling 
> serial terminals.
> 
> A pty is conceptually a null-modem cable connected between two 
> infinitely-fast serial ports on the same machine, although the slave 
> will still report an actual baud rate if queried.  (Run "stty" with no 
> arguments under script(1), an ssh session, or an X11 terminal emulator 
> to see what a pty slave looks like on your machine.)
> 
> In your case 1, the pty subsystem is not used and output is collected 
> over a pipe.  Using "./a.out > out; xxd out" would produce the same 
> results.  In cases 2 and 3, there is a pty involved, either set up by 
> script(1) or by sshd (assuming you meant "enable putty logging" in case 
> 3) that performs the standard terminal translations.  In all cases, 
> strace(1) will show the exact string written to the pty slave device, 
> which will not include any extra CRs because *those* *are* *inserted* 
> *by* *the* *kernel* *terminal* *driver* as the data is transferred to 
> the pty master device's read queue.
> 
> This insertion of carriage returns is expected and standardized behavior 
> in POSIX and is the reason Unix could use bare LF as end-of-line even 
> though hardware terminals always needed CRLF.  CP/M (and therefore 
> MS-DOS which began its existence as a cheap CP/M knockoff) did not have 
> this translation layer and instead dumped the complexity of a two-octet 
> end-of-line sequence on user programs, leading to much confusion even 
> today.  This is not a Wine issue, although the terminal escape sequences 
> in your original issue *were* from Wine.  Note that the number of excess 
> carriage returns that a DejaGnu testsuite must be prepared to discard is 
> unspecified because running tests on remote targets may result in *any* 
> *number* of CRs preceding each LF by the time the results reach the test 
> driver machine in more complex testing lab environments.
> 
> 
> -- Jacob

Agree

Re: testsuite under wine

[NightStrike]

On Thu, Jan 5, 2023 at 10:33 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>
> NightStrike wrote:
> > On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
> >
> >> NightStrike wrote:
> >>
> >>> On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
> >>>
> >>>> [...]
> >>> 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.
> >>>
> >>>
> >> I doubt that Wine is doing that translation.  MinGW libc produces output
> >> conformant to Windows conventions, so printf("\n") on a text handle
> >> emits "\r\n", which Wine passes along.  POSIX convention is that "\n" is
> >> translated to "\r\n" in the kernel terminal driver upon output, so the
> >> kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding
> >> "\r\r\n" at the pty master end.  This is why DejaGnu testsuites must be
> >> prepared to discard excess carriage returns.  The first CR came from
> >> MinGW libc; the second CR came from the kernel terminal driver; the LF
> >> was ultimately passed through.
> >>
> >
> > Jacek and I have been digging into this on IRC, and he's been very
> > helpful in trying to get further, but we're still stuck.  We tried to
> > be more introspective, inserting strace both as "strace script wine"
> > and as "script strace wine".  We tried running just "wine a.exe"
> > without any extra glue, and logging the raw SSH packets from putty.
> > After many iterations on these and other tests, Jacek finally had the
> > idea to try removing Windows entirely from the equation, and we ran
> > with a purely unix program / compiler combination:
> >
> > #include <unistd.h>
> >
> > int main()
> > {
> >         write(1, "test\r\n", 6);
> >         return 0;
> > }
> >
> > (and also as "test\n", 5)
> >
> > In both versions, the following was observed:
> >
> > case 1) ./a.out | xxd
> > case 2) script -c ./a.out out; xxd out
> > case 3) enable putting logging, ./a.out
> >
> > In case 1, xxd showed no extra \r's.  In cases 2 and 3, there was an
> > extra \r (either 0d 0d 0a for test\r\n, or 0d 0a for test\n).
> >
> > So, is it possible after all of this back and forth regarding mingw,
> > wine, and others, that it's down to the write() system call that's
> > inserting extra \r's?  Is this expected?
> >
>
> "This is why DejaGnu testsuites must be prepared to discard excess
> carriage returns."
>
> The write(2) system call inserts nothing and simply hands off the buffer
> to the relevant part of the kernel I/O subsystem.  (The kernel in POSIX
> is *not* a monolithic black box.)  When stdout for your test program is
> a pty slave, that relevant part is the kernel terminal driver.  The
> kernel terminal driver is converting "\n" to "\r\n" upon output to the
> associated port, since hardware terminals typically *do* require CRLF.
> The associated port in this case is virtual and part of the kernel pty
> subsystem, which presents octets written to that port to its associated
> pty master device.  The user-visible pty slave device acts just like a
> serial terminal, including all translations normally done for handling
> serial terminals.
>
> A pty is conceptually a null-modem cable connected between two
> infinitely-fast serial ports on the same machine, although the slave
> will still report an actual baud rate if queried.  (Run "stty" with no
> arguments under script(1), an ssh session, or an X11 terminal emulator
> to see what a pty slave looks like on your machine.)
>
> In your case 1, the pty subsystem is not used and output is collected
> over a pipe.  Using "./a.out > out; xxd out" would produce the same
> results.  In cases 2 and 3, there is a pty involved, either set up by
> script(1) or by sshd (assuming you meant "enable putty logging" in case
> 3) that performs the standard terminal translations.  In all cases,
> strace(1) will show the exact string written to the pty slave device,
> which will not include any extra CRs because *those* *are* *inserted*
> *by* *the* *kernel* *terminal* *driver* as the data is transferred to
> the pty master device's read queue.
>
> This insertion of carriage returns is expected and standardized behavior
> in POSIX and is the reason Unix could use bare LF as end-of-line even
> though hardware terminals always needed CRLF.  CP/M (and therefore
> MS-DOS which began its existence as a cheap CP/M knockoff) did not have
> this translation layer and instead dumped the complexity of a two-octet
> end-of-line sequence on user programs, leading to much confusion even
> today.  This is not a Wine issue, although the terminal escape sequences
> in your original issue *were* from Wine.  Note that the number of excess
> carriage returns that a DejaGnu testsuite must be prepared to discard is
> unspecified because running tests on remote targets may result in *any*
> *number* of CRs preceding each LF by the time the results reach the test
> driver machine in more complex testing lab environments.

First, I just want to thank you for your patience.  You are putting a
lot of effort into these replies, and it is appreciated.

I did another little test to try to better understand your point.  I
ran a linux native testsuite under a simulator that just sets SIM to "
".  This resulted in extra ^M's also, although many tests pass because
they're already looking for \r\n to accommodate windows.  So I think
I've come around to grasp what you've been heroically re-explaining...

So if we have to modify every test in the entire testsuite to check
for zero or more \r's followed by zero or more \n's, would it be
better to add a dg-output-line proc that does this automatically
everywhere?  I feel like changing every output pattern test won't be
too maintainable.  You had mentioned previously modifying ${tool}_load
to filter out extra \r's, but I couldn't see where or how to do that.

For completeness, setting a random selection of tests to look for
\r*\n? worked (this would cover even deprecated systems that only use
CR as well as flagging the weird rust case of \r\r\n\n as bad).

Re: testsuite under wine

[Jacob Bachmeyer]

NightStrike wrote:
> [...]
> I did another little test to try to better understand your point.  I
> ran a linux native testsuite under a simulator that just sets SIM to "
> ".  This resulted in extra ^M's also, although many tests pass because
> they're already looking for \r\n to accommodate windows.  So I think
> I've come around to grasp what you've been heroically re-explaining...
>
> So if we have to modify every test in the entire testsuite to check
> for zero or more \r's followed by zero or more \n's, would it be
> better to add a dg-output-line proc that does this automatically
> everywhere?

Two problems:  first, you need zero-or-more \r and *one*-or-more \n.  
Second, dg-output is not defined as an anchored match, and therefore 
cannot do this automatically.

>   I feel like changing every output pattern test won't be
> too maintainable.  You had mentioned previously modifying ${tool}_load
> to filter out extra \r's, but I couldn't see where or how to do that.
>
> For completeness, setting a random selection of tests to look for
> \r*\n? worked (this would cover even deprecated systems that only use
> CR as well as flagging the weird rust case of \r\r\n\n as bad).

Do not worry about classic Mac OS---running DejaGnu on that platform is 
not possible, nor is it possible to run test programs remotely on that 
platform.  Classic Mac OS is a pure-GUI system with no command interface 
whatsoever.  Even the Mac port of Tcl simply /does/ /not/ /have/ the Tcl 
exec(n) command.  Due to limitations of the platform, porting Expect to 
classic Mac OS is simply not possible.  Any compatibility layer would be 
reasonably expected to translate CR<->LF, if, for example, someone wrote 
a telnet server (and associated POSIX-alike environment) for Mac OS.

The later Mac OS X is a quasi-POSIX mostly compatible with the GNU 
system that uses POSIX line endings.  DejaGnu should run normally there.

Are there other systems that used bare CR as end-of-line?  If not, the 
correct pattern is therefore {\r*\n} (here written using braces as 
quotes around the pattern).


-- Jacob

Re: testsuite under wine

[NightStrike]

On Tue, Jan 10, 2023 at 9:30 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>
> NightStrike wrote:
> > [...]
> > I did another little test to try to better understand your point.  I
> > ran a linux native testsuite under a simulator that just sets SIM to "
> > ".  This resulted in extra ^M's also, although many tests pass because
> > they're already looking for \r\n to accommodate windows.  So I think
> > I've come around to grasp what you've been heroically re-explaining...
> >
> > So if we have to modify every test in the entire testsuite to check
> > for zero or more \r's followed by zero or more \n's, would it be
> > better to add a dg-output-line proc that does this automatically
> > everywhere?
>
> Two problems:  first, you need zero-or-more \r and *one*-or-more \n.
> Second, dg-output is not defined as an anchored match, and therefore
> cannot do this automatically.

"or more" \n is valid?  That would make the rust bug of \r\r\n\n pass
when I assume it shouldn't.

> >   I feel like changing every output pattern test won't be
> > too maintainable.  You had mentioned previously modifying ${tool}_load
> > to filter out extra \r's, but I couldn't see where or how to do that.
> >
> > For completeness, setting a random selection of tests to look for
> > \r*\n? worked (this would cover even deprecated systems that only use
> > CR as well as flagging the weird rust case of \r\r\n\n as bad).
>
> Do not worry about classic Mac OS---running DejaGnu on that platform is
> not possible, nor is it possible to run test programs remotely on that
> platform.  Classic Mac OS is a pure-GUI system with no command interface
> whatsoever.  Even the Mac port of Tcl simply /does/ /not/ /have/ the Tcl
> exec(n) command.  Due to limitations of the platform, porting Expect to
> classic Mac OS is simply not possible.  Any compatibility layer would be
> reasonably expected to translate CR<->LF, if, for example, someone wrote
> a telnet server (and associated POSIX-alike environment) for Mac OS.
>
> The later Mac OS X is a quasi-POSIX mostly compatible with the GNU
> system that uses POSIX line endings.  DejaGnu should run normally there.
>
> Are there other systems that used bare CR as end-of-line?  If not, the
> correct pattern is therefore {\r*\n} (here written using braces as
> quotes around the pattern).

Maybe none that matter.  From
https://en.wikipedia.org/wiki/Newline#Representation:

Commodore 8-bit machines (C64, C128), Acorn BBC, ZX Spectrum, TRS-80,
Apple II series, Oberon, the classic Mac OS, MIT Lisp Machine and OS-9

The article also goes on to mention that OpenVMS and RSX-11 can be
configured to use CR.

Re: testsuite under wine

[Jacob Bachmeyer]

NightStrike wrote:
> On Tue, Jan 10, 2023 at 9:30 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>   
>> NightStrike wrote:
>>     
>>> [...]
>>> I did another little test to try to better understand your point.  I
>>> ran a linux native testsuite under a simulator that just sets SIM to "
>>> ".  This resulted in extra ^M's also, although many tests pass because
>>> they're already looking for \r\n to accommodate windows.  So I think
>>> I've come around to grasp what you've been heroically re-explaining...
>>>
>>> So if we have to modify every test in the entire testsuite to check
>>> for zero or more \r's followed by zero or more \n's, would it be
>>> better to add a dg-output-line proc that does this automatically
>>> everywhere?
>>>       
>> Two problems:  first, you need zero-or-more \r and *one*-or-more \n.
>> Second, dg-output is not defined as an anchored match, and therefore
>> cannot do this automatically.
>>     
>
> "or more" \n is valid?

Only if you are ignoring blank lines.  Note that you had earlier said 
zero-or-more \r and zero-or-more \n, which would be a pattern that can 
match with zero length.

>   That would make the rust bug of \r\r\n\n pass
> when I assume it shouldn't.
>   

The pattern that I suggested as correct is zero-or-more \r followed by 
exactly one \n.  If you are ignoring blank lines in buffered text, but 
/not/ in live Expect, you can use {[\r\n]+} (any non-empty sequence of 
\r and \n) but this will /not/ work with live Expect, because it can 
match a prefix of the intended text.

>>>   I feel like changing every output pattern test won't be
>>> too maintainable.  You had mentioned previously modifying ${tool}_load
>>> to filter out extra \r's, but I couldn't see where or how to do that.
>>>
>>> For completeness, setting a random selection of tests to look for
>>> \r*\n? worked (this would cover even deprecated systems that only use
>>> CR as well as flagging the weird rust case of \r\r\n\n as bad).
>>>       
>> Do not worry about classic Mac OS---running DejaGnu on that platform is
>> not possible, nor is it possible to run test programs remotely on that
>> platform.  Classic Mac OS is a pure-GUI system with no command interface
>> whatsoever.  Even the Mac port of Tcl simply /does/ /not/ /have/ the Tcl
>> exec(n) command.  Due to limitations of the platform, porting Expect to
>> classic Mac OS is simply not possible.  Any compatibility layer would be
>> reasonably expected to translate CR<->LF, if, for example, someone wrote
>> a telnet server (and associated POSIX-alike environment) for Mac OS.
>>
>> The later Mac OS X is a quasi-POSIX mostly compatible with the GNU
>> system that uses POSIX line endings.  DejaGnu should run normally there.
>>
>> Are there other systems that used bare CR as end-of-line?  If not, the
>> correct pattern is therefore {\r*\n} (here written using braces as
>> quotes around the pattern).
>>     
>
> Maybe none that matter.  From
> https://en.wikipedia.org/wiki/Newline#Representation:
>
> Commodore 8-bit machines (C64, C128), Acorn BBC, ZX Spectrum, TRS-80,
> Apple II series, Oberon, the classic Mac OS, MIT Lisp Machine and OS-9
>   

DejaGnu is not going to run on any of those, and remote testing with any 
of those as targets gets ... "interesting" ... very quickly.

Oberon, similarly to classic MacOS simply does not have a command line, 
although it /does/ have enough infrastructure that implementing some 
kind of line-oriented command interface could be feasible and some 
Oberon versions do have network capability.  Nonetheless, the entire 
Oberon system is written in its own language, so a testsuite for an 
Oberon target would be expected to be specially written accordingly.

I already mentioned classic MacOS.

Lisp Machines evaluate similarly to Oberon, using their own language for 
all software (in this case, Lisp) with the additional element of being 
highly unlikely to be found outside of a computer museum, having never 
been common.

OS-9 is interesting, but is an oddball nonfree system with niche uses.  
Nonetheless, it does have a shell, so it fits in with the others 
mentioned below.

The rest are various 8-bit systems, where some level of remote testing 
might be possible over a serial line, but see stty(1) and the icrnl and 
inlcr options for that case (the POSIX terminal driver can translate 
incoming CR to LF and vice versa).

> The article also goes on to mention that OpenVMS and RSX-11 can be
> configured to use CR.
>   

Those systems actually store each line as a separate record; the /same/ 
file can be read with LF or CRLF by simply asking, if I read that 
article correctly.


-- Jacob

Re: testsuite under wine

[Jerry D]

On 1/4/23 6:50 PM, NightStrike via Fortran wrote:
> On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>> NightStrike wrote:
>>> On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> 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 close, and yet so far...  script(1) /also/ uses a pty, so it is
>> getting the same translations as Expect and therefore DejaGnu.
>>
>>> 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.
>>>
>>
>> I doubt that Wine is doing that translation.  MinGW libc produces output
>> conformant to Windows conventions, so printf("\n") on a text handle
>> emits "\r\n", which Wine passes along.  POSIX convention is that "\n" is
>> translated to "\r\n" in the kernel terminal driver upon output, so the
>> kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding
>> "\r\r\n" at the pty master end.  This is why DejaGnu testsuites must be
>> prepared to discard excess carriage returns.  The first CR came from
>> MinGW libc; the second CR came from the kernel terminal driver; the LF
>> was ultimately passed through.
> 
> Jacek and I have been digging into this on IRC, and he's been very
> helpful in trying to get further, but we're still stuck.  We tried to
> be more introspective, inserting strace both as "strace script wine"
> and as "script strace wine".  We tried running just "wine a.exe"
> without any extra glue, and logging the raw SSH packets from putty.
> After many iterations on these and other tests, Jacek finally had the
> idea to try removing Windows entirely from the equation, and we ran
> with a purely unix program / compiler combination:
> 
> #include <unistd.h>
> 
> int main()
> {
>          write(1, "test\r\n", 6);
>          return 0;
> }
> 
> (and also as "test\n", 5)
> 
> In both versions, the following was observed:
> 
> case 1) ./a.out | xxd
> case 2) script -c ./a.out out; xxd out
> case 3) enable putting logging, ./a.out
> 
> In case 1, xxd showed no extra \r's.  In cases 2 and 3, there was an
> extra \r (either 0d 0d 0a for test\r\n, or 0d 0a for test\n).
> 
> So, is it possible after all of this back and forth regarding mingw,
> wine, and others, that it's down to the write() system call that's
> inserting extra \r's?  Is this expected?

I have reproduced this test with C.  I suspect that the 'write' function 
was written to accommodate non standard behavior of windows which 
expects a CR-LF.  This means that POSIX compliant code is adjusted by 
the C or gfortran libraries to emit a extra CR so that on Windows it 
will just work ok.  So the test is doing exactly what you are telling it 
to do.  An LF causes the run times to add a CR in front.

With libgfortran I remember implementing some of this code myself and 
this is the reason, to keep applications happy on Windows.

So the gfortran tests we wrote to accept either a CR or a CR-LF, and in 
the test code to only issue a normal line ending which on UNIX will be 
an LF and Windows an CR-LF.

I lose track of details in between looking ta the test cases. let me 
know one of them to study that is gfortran side and will see what it is 
doing.

Jerry