From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 433BE1F461 for ; Sun, 8 Sep 2019 17:59:53 +0000 (UTC) Received: from localhost ([::1]:49984 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i71Tb-00011l-Vz for normalperson@yhbt.net; Sun, 08 Sep 2019 13:59:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41848) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i71TZ-00011f-7I for bug-gnulib@gnu.org; Sun, 08 Sep 2019 13:59:50 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:50031) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i71TY-0007OD-IX; Sun, 08 Sep 2019 13:59:48 -0400 Received: from pool-98-118-0-140.bstnma.fios.verizon.net ([98.118.0.140]:58598 helo=homebase.home) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i71TY-0007ZW-8s; Sun, 08 Sep 2019 13:59:48 -0400 Message-ID: Subject: Re: [PATCH] findprog: Support searching in a specified path string From: Paul Smith To: Bruno Haible Date: Sun, 08 Sep 2019 13:59:47 -0400 In-Reply-To: <2906116.4hz8Lom1yu@omega> References: <20190906231011.32454-1-psmith@gnu.org> <2257421.7xAeYRz9PB@omega> <2906116.4hz8Lom1yu@omega> Organization: GNU's Not UNIX! Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.1-2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: psmith@gnu.org Cc: bug-gnulib@gnu.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" On Sun, 2019-09-08 at 19:48 +0200, Bruno Haible wrote: > > My suggestion was that BOTH these functions should not assume the CWD > > if PATH is empty or missing, not that they should behave differently. > > OK. But what, do you suggest, should the functions do when confronted to > an empty path? What is 'make' supposed to do when the Makefile defines > PATH = > ? Very simply, in both the "unset PATH" and "PATH=" cases, it should report all unqualified (containing no slashes) programs as not found. That is clearly allowed by POSIX and IMO is the most expected, and secure, behavior. Having PATH= be equivalent to PATH=., and even moreso "unset PATH" be equivalent to PATH=., is quite odd IMO. > > My personal opinion is that it's not difficult to come up with ways > > findprog can be useful _in addition_ to simply being a precursor to > > exec > > In this case we should probably add a flag argument that tells the > function to do the complete lookup also when the progname contains a > slash. For now, until someone claims that this functionality would > be actually useful, I'll leave it as is. I think this will not be needed. In the event that someone does need this they can simply use the findprog-in module instead.