From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) by sourceware.org (Postfix) with ESMTPS id D3526385BAED; Fri, 24 Jun 2022 18:30:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D3526385BAED Received: by mail-ed1-x52b.google.com with SMTP id e2so4647825edv.3; Fri, 24 Jun 2022 11:30:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:references :message-id:mime-version:content-transfer-encoding; bh=0MEFteKj4ptYgTclqWaG06xZniEtdyhdI+QqVtVCWA4=; b=46tC6S7KQdLOV/7YLEiwGjQi+bxPeAs+mYhONYFVtJs4ykTdGZqkjTuPLuPWzn82pe 0F/4o7c8yez0ZviQyyPK5We/l82xYWcktmKJRTQckb/75foiCcSc3vGGDqwJ/Xd9XZhv LEJOF5rawlJFQ2z1Urt2OGiRNdNgcQ/PX9xcWKBjxn5I2L8UUzAHbN2v53Gs3/SFERfB 82DO6X6b1lU5D7J4RtQjlJLefxN7J7E4tgt+j5tSdds/8dno5epb3RQMiMwEna85lg0i kNKnlGUm71GGvQmtlDnErfLcoUy8FbKoXvCSDDrVL1jpMEpSeOE1OdlgSNSCtxEuHhVu lqOw== X-Gm-Message-State: AJIora/POSiD3FbHDf4XXed2au86eIbxHBNYVPtGBVUvAZWWYN7Jti2J HSlqP4rClmmsFSdLGAE6N7s= X-Google-Smtp-Source: AGRyM1swHbWic8JpdU0shgwPDP1sXdO62PuBXRYUEOVLEDrFdzYlLGuH3rqsIA5mATaXi8ceI4aOfQ== X-Received: by 2002:a05:6402:50d2:b0:435:8c44:8715 with SMTP id h18-20020a05640250d200b004358c448715mr535062edb.49.1656095455501; Fri, 24 Jun 2022 11:30:55 -0700 (PDT) Received: from ?IPv6:::1? ([2001:4bb8:109:6a4c::4d2:a6b5]) by smtp.gmail.com with ESMTPSA id d25-20020a50fe99000000b004355998ec1asm2567231edt.14.2022.06.24.11.30.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Jun 2022 11:30:55 -0700 (PDT) Date: Fri, 24 Jun 2022 20:30:49 +0200 From: Bernhard Reutner-Fischer To: Rainer Orth , Xi Ruoyao CC: fortran@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: [PATCH 6/8] fortran: use grep -F instead of fgrep In-Reply-To: References: <74ea0c62ebe19db186263053e4051f81d46e9da4.camel@xry111.site> <3fe5664607c4e530fbb91048c2e363ddee917250.camel@xry111.site> <20220624131331.0b157480@nbbrfq> <09114af24f7f09eb2fa6c7dc743de18480d8bd7d.camel@xry111.site> Message-ID: <35F08104-A789-4648-8AB5-DFC20F493E51@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2022 18:30:58 -0000 On 24 June 2022 14:35:20 CEST, Rainer Orth wrote: >Hi Xi, > >> On Fri, 2022-06-24 at 13:13 +0200, Bernhard Reutner-Fischer wrote: >> >>> > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if $(SHELL) -c 'install-i= nfo --version | sed 1q | fgrep -s -v >>> > -i debian' >/dev/null 2>&1; then \ >>> > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if $(SHELL) -c 'install-i= nfo --version | sed 1q | grep -F -s -v >>> > -i debian' >/dev/null 2>&1; then \ >>> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 echo " instal= l-info --delete --info-dir=3D$(DESTDIR)$(infodir) >>> > $(DESTDIR)$(infodir)/gfortran=2Einfo"; \ >>> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 install-info = --delete --info-dir=3D$(DESTDIR)$(infodir) >>> > $(DESTDIR)$(infodir)/gfortran=2Einfo || : ; \ >>> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0else : ; fi; \ >>>=20 >>> I'd replace -s >/dev/null 2>&1 with -q while at it=2E >>>=20 >>> But why is -F used here in the first place? >>> I do not see much in debian that can be interpreted as a regex? >> >> I'm not sure=2E It was there since 2004=2E Perhaps the author thinks = fgrep >> may save several CPU cycles :)=2E I'll just use a plain grep in PATCH = v2=2E >> >> Rainer: do you have some idea about the availability of "-q" on >> different hosts? If you agree I'll use it instead of -s > /dev/null >> too=2E > >again, the autoconf manual warns agains it, even more so against -s=2E >That's the first reference for portability issues and shouldn't be >ignored without good reason=2E > >In the GCC and Solaris context, /bin/grep supports both -q and -s in >Solaris 11=2E3 and 11=2E4=2E It doesn't support -q on Solaris 10, though >(again, no longer relevant for GCC)=2E The good reason I would bring forward is that the systems mentioned in the= autoconf docs are all not supported anymore (IRIX, ancient or old Solaris = etc)=2E Furthermore, grep(1) is required by POSIX to support -q since at least 199= 7; see https://pubs=2Eopengroup=2Eorg/onlinepubs/007908799/xcu/grep=2Ehtml That's about 25 years now, so everybody had plenty of time to implement th= is specific part, which is even trivial to implement for this particular ca= se of grep -q=2E All in all i think that we should not be held hostage by such systems any = longer, at least for such cases that are trivial to fix to conformance=2E O= f course that may be just /me=2E Iff fixing egrep or fgrep occurrences though, we should use plain grep wh= ere applicable, like in this case, IMO=2E thanks,