From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc29.google.com (mail-oo1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) by sourceware.org (Postfix) with ESMTPS id E53423858D33; Wed, 11 Jan 2023 02:30:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E53423858D33 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-xc29.google.com with SMTP id d2-20020a4ab202000000b004ae3035538bso3709074ooo.12; Tue, 10 Jan 2023 18:30:10 -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=mClpkvWfs5ZqYdAgxt6B0wB71M5AM2UZ+gT/bws3bcg=; b=hjAntnMoN2FP2BS8eJeTQYTA6u8Qg0HxkpwbWXX+Jd6DYshp918ZGqSzS4ca8CWZsq 8QjaAhUIpt65eQoFNH7HpsBO2Vnzi40+LkFxdWbWDTW5cJHk4BY8UK4YBK1r1fikjc2z YHU+acEjAd7NSI2k+tu7S9CP6Y6jQAfCUPpD/2/HDIlAFeTBP2yggMl7WXJYHjzq4KAJ pK3l75beZqLYxkmMgOsTeFpv8+sGYHHKyP08hEIcA+HPbTQ8H2EoBw9FvCSCFzrzt5p3 weuoW8soB5GUFCYBCzqdePu4RVJak+r2yllrQ8GacKiqV2jykGMBbxq/tt+1T5R1/lpH KXVA== 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=mClpkvWfs5ZqYdAgxt6B0wB71M5AM2UZ+gT/bws3bcg=; b=BDf7HfpRRjUtecHw3mwLydQ4W3vqElMNPe3PcU7m4x96yS5uK9Go1fagmZey9zzqik OoqO4H8tbSlZwpRI8ZLsCkKMJxKAobq9xH0rWMRq7MJup1uRLviKjT5ZK56c2xtTRT71 IyS1yBEtd4a7RO+nr1Kan1qxCDwHLBuKYyLMX44SITSd6I77IqrkdevbiUGi7e0enzle 4Kbuyuz808oXzkEJ2g8TBjDQitvzcYhjmruvueqDZfaiSjQOQkRUm8sGA6sQT9NFSZQe 7dgKj6JtLnUtVTlL9VR6beJAU9TmWuKSU069Df971LDnttnqw7ZqQKIfs0q2o/XbwLmc 21TQ== X-Gm-Message-State: AFqh2kqI6dD+hRCAbhzfloN6K9ud4lDkjkq8JtEPUQALrma9SFykVF+G suGlfk+AY8Ys8egyMgeJV9w= X-Google-Smtp-Source: AMrXdXvC9kU+MYGxHhYPVicI1DKjTTdPdbAH6TF+CxvB5/DwIVhWnPvoaaDMSRnslx3AoNXzTu1OZg== X-Received: by 2002:a4a:928f:0:b0:4f1:e1c7:2723 with SMTP id i15-20020a4a928f000000b004f1e1c72723mr7848398ooh.8.1673404210145; Tue, 10 Jan 2023 18:30:10 -0800 (PST) Received: from [127.0.0.1] ([70.133.144.146]) by smtp.gmail.com with ESMTPSA id w15-20020a4ae08f000000b004f1f6b25091sm4378741oos.41.2023.01.10.18.30.09 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 10 Jan 2023 18:30:09 -0800 (PST) Message-ID: <63BE1F2F.8030609@gmail.com> Date: Tue, 10 Jan 2023 20:30:07 -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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.2 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: > [...] > 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