From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from re-prd-fep-046.btinternet.com (mailomta2-re.btinternet.com [213.120.69.95]) by sourceware.org (Postfix) with ESMTPS id 4EAAF38582A2 for ; Fri, 4 Nov 2022 13:50:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4EAAF38582A2 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dronecode.org.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=dronecode.org.uk Received: from re-prd-rgout-002.btmx-prd.synchronoss.net ([10.2.54.5]) by re-prd-fep-046.btinternet.com with ESMTP id <20221104135043.GNPG3123.re-prd-fep-046.btinternet.com@re-prd-rgout-002.btmx-prd.synchronoss.net>; Fri, 4 Nov 2022 13:50:43 +0000 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com; bimi=skipped X-SNCR-Rigid: 613A8DE84103820D X-Originating-IP: [81.153.98.206] X-OWM-Source-IP: 81.153.98.206 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedvgedrvddugdehhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemuceutffkvffkuffjvffgnffgvefqofdpqfgfvfenuceurghilhhouhhtmecufedtudenucenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeflohhnucfvuhhrnhgvhicuoehjohhnrdhtuhhrnhgvhiesughrohhnvggtohguvgdrohhrghdruhhkqeenucggtffrrghtthgvrhhnpeffkeeigfdujeehteduiefgjeeltdelgeelteekudetfedtffefhfeufefgueettdenucfkphepkedurdduheefrdelkedrvddtieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopegludelvddrudeikedruddruddtiegnpdhinhgvthepkedurdduheefrdelkedrvddtiedpmhgrihhlfhhrohhmpehjohhnrdhtuhhrnhgvhiesughrohhnvggtohguvgdrohhrghdruhhkpdhnsggprhgtphhtthhopedvpdhrtghpthhtohepnhgvfihlihgssehsohhurhgtvgifrghrvgdrohhrghdprhgtphhtthhopehvrghpihgvrhesghgvnhhtohhordhorhhg X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.106] (81.153.98.206) by re-prd-rgout-002.btmx-prd.synchronoss.net (5.8.716.04) (authenticated as jonturney@btinternet.com) id 613A8DE84103820D; Fri, 4 Nov 2022 13:50:43 +0000 Message-ID: <9b242eca-08ba-cc4f-fc2c-b8ad72992c37@dronecode.org.uk> Date: Fri, 4 Nov 2022 13:50:42 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCH] makedocbook: Fix false report of unhandled texinfo command Content-Language: en-GB To: Mike Frysinger , "newlib@sourceware.org" References: <20221031095914.2277-1-jon.turney@dronecode.org.uk> From: Jon Turney In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3568.6 required=5.0 tests=BAYES_00,FORGED_SPF_HELO,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,NICE_REPLY_A,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_NONE,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: On 31/10/2022 12:28, Mike Frysinger wrote: > On 31 Oct 2022 09:59, Jon Turney wrote: > > i guess the feedback below isn't exactly about new code even if it's relevant ... > >> + # fail if there are unhandled texinfo commands >> + match = re.search('(? > regexes should use raw strings (i.e., this is missing the r prefix) > >> + if match: >> + print("texinfo command '%s' remains in output" % match.group(), file=sys.stderr) > > this is a little dangerous in general as match.group() could return a tuple, > and this would fail. if you want to use %, you should force a tuple. > print("..." % (match.group(),), ...) I must be missing something here, because I'm not sure in what sense 'could' is being used. I think match.group() is defined to be the same as match.group(0), which always returns a single string. (I guess this could be written explicitly). So the danger pointed out seems to be that if parts of the code were changed, without making other necessary changes, it would be wrong. But I'm not sure the suggested change just to avoid that future possibility makes things better or clearer. > >> + exit(1) > > scripts should never use exit(), only sys.exit(). although i see the current > script gets this wrong in a lot of places. > > also you can simplify this -- sys.exit accepts a string that it'll print to > stderr and then exit non-zero. > sys.exit(".....") Yes, this is one of the first things I wrote in python, and unfortunately, it shows. I've posted a revised patch-set.