From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc33.google.com (mail-oo1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) by sourceware.org (Postfix) with ESMTPS id 12CFE3858C66; Thu, 12 Jan 2023 04:11:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 12CFE3858C66 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oo1-xc33.google.com with SMTP id d2-20020a4ab202000000b004ae3035538bso4548538ooo.12; Wed, 11 Jan 2023 20:11:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:references:subject:cc:to :mime-version:user-agent:reply-to:from:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=JidpqAOsNJyQc7iSEJJ3mCfu/DcYyBeUh7kWNQMI9Yc=; b=axpL4onuK7Ds/w6B7n6O5w4O1WF5ukU1CQAGkDjImp2fY6D9XTZ+YKNGf1Si8gfnJT EHOf2qHMKw2YLGAcjbESsyGE2yWySUrpyfXjZJNiUcRP0fCVTI7bK81bumiIWWcxZ6gv bkz6RmZBmvSo4q+vIcwpXGbpk/mYEbQSs31grJeKiWImbAHC4yXAfHNjIHCtN53rLpnv WlzQ7kpK8ze/hQmbOm0zZ/T5VuxxBGDywqsEkX6+d8Iq6zgZY4cSHpBoCHEbR1kftVW2 w2TDuddat6Ehx4TXu0IH+h7hr+b5agRlgVmzdHyv4kVDFtVz+71ToFbe7VZnacwO76hb +7OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:references:subject:cc:to :mime-version:user-agent:reply-to:from:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=JidpqAOsNJyQc7iSEJJ3mCfu/DcYyBeUh7kWNQMI9Yc=; b=BY66feyCoBoA2eoiZS0zCF+F9YphWp8gYprNEJJYvCFlLiJFgDbsO0c6IUgjdzznSK 0kzhfH+5iG/5H9FqLiQZ0Mr/xmrx+DwJpRGQbJHv7+v+q1nvuJZOesYDOQBEbsbFZqar OvwDAe1haZlqxv/COQdR08iAomNN6g2M2Cj99FKvEMRl2yW/FsESNPdkPWA1HjmGuR8U HG0kYBoyeuJ4DLfvMy9LeBgOpDRp6fPGO61YVTYbrAmP3qi1xIbEcXUWod5no6vnGS9j M7KafnCfb5y7ckrJzXxfIBxl9Ui4SRcn34OtUjMTFGOtvY8oBdCNJSoqM1n8yZcoW+Xb V57A== X-Gm-Message-State: AFqh2koCZNQLNlUHr+1dzpvKqJE2KHfjXyDFBbAm1MCVQiPe9tS1w4Uy bNqrMJqiNmwatLruL80CzPw= X-Google-Smtp-Source: AMrXdXtreJoDkJAsRp6W5PuUnhxSVJnd1Zz1jm8ytMieV1eJD8NINGPpEINmGePpYf6OYu/amYPQIw== X-Received: by 2002:a4a:da51:0:b0:4a4:b400:3e74 with SMTP id f17-20020a4ada51000000b004a4b4003e74mr36662525oou.8.1673496676324; Wed, 11 Jan 2023 20:11:16 -0800 (PST) Received: from [127.0.0.1] ([70.133.144.146]) by smtp.gmail.com with ESMTPSA id x18-20020a4ac592000000b004a3543fbfbbsm7859343oop.14.2023.01.11.20.11.15 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 11 Jan 2023 20:11:15 -0800 (PST) Message-ID: <63BF8862.5030807@gmail.com> Date: Wed, 11 Jan 2023 22:11:14 -0600 From: Jacob Bachmeyer Reply-To: jcb62281@gmail.com User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.22) Gecko/20090807 SeaMonkey/1.1.17 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: NightStrike CC: Jacek Caban , fortran@gcc.gnu.org, Eric Pouech , "gcc@gcc.gnu.org" , dejagnu@gnu.org Subject: Re: testsuite under wine References: <639FE88D.7090408@gmail.com> <7cb45ab2-cc6e-c502-5592-51ffabcbc6f8@codeweavers.com> <63A3DF0E.1050902@gmail.com> <63A67964.6080902@gmail.com> <63B7967B.60502@gmail.com> <63BE1F2F.8030609@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,FREEMAIL_REPLYTO_END_DIGIT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 >>> 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