Re: testsuite under wine

[Jacob Bachmeyer <jcb62281@gmail.com>]

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