[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: testsuite under wine

From: Jacob Bachmeyer
Subject: Re: testsuite under wine
Date: Wed, 11 Jan 2023 22:11:14 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090807 SeaMonkey/1.1.17 Mnenhy/

NightStrike wrote:
On Tue, Jan 10, 2023 at 9:30 PM Jacob Bachmeyer <> 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
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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]