X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=GUGrN3DI803qW1Xp
	+IiDPzPRNnRJmnwJjQmuKZFBuYY9p4JyZuQl5+LYPJMfiz+SoiwooVpNUGI+GhNR
	wAfV/F1hOsUMdU3Lcsk8ucM5JNIyTnKHEODCd1PquOm9BdqaBYbDQCI8UpSJph5j
	Yl0jdNMMnoB0BMMdEAS1zAH3ZBg=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=SyTs/UdWC3Q3dIzuEQvmFK
	UNOuY=; b=AXQef48d1IgDr5wPQhHxv5aZAvNe6nUKrlPaTLbsRexnQ29TLz0gFK
	t12ZU1f78Mu/Mt/++9aI065BnWeD4fzW+MvSXyDUyqatEwPebLZLTIqYI5pr+oK1
	OLhQzN/MxcTtvlHT08IAR1agBoXx76GbArt5wpwdqtBlt1VtTnMCI=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=H*i:sk:7b94712, H*f:sk:7b94712, H*MI:sk:7b94712, impose
X-HELO:	mail-io0-f178.google.com
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=TUyg7KAIGz0645407afAa6XlZ3HRLpampSx0VON28LI=; b=RQ0kk8fGhxKC2LfeA4V1ioAz4qlUN8nSDqwumakMOJfj2XyM8ZC9089jb+Ilid5MA8 pm3Xms0Pt+tRYs3wXDV81LNAM1P072wzMwQK61blLBHZElkG3EqkaYe4APE8ghXlUxuP LZ62FE5rWLzakZtyvR+o9thFhMuGTzrtqIKPrQ/2DRXKOy/BU4OU9z4icVIf5TaVBbBu Cin0TQTMjD1xQM1bIk4GMf92//++1AGbOXN8F3imX624q2PBwPOLkNhj0vm2VXDqrmyn A+rc/FbvG036IC8SkXI5jjhtXWrffiQBYth8ufFlvtGnfDMW8kte6o/ylzcKhUBH3iWu 6Yjg==
X-Gm-Message-State:	AN3rC/5uVSnGxtqe77qwA9aJlO847PcVt4TAMw9tXIaVLNYqDcA9HKf318+1okn2Z1QZjQ==
X-Received:	by 10.107.149.20 with SMTP id x20mr2013278iod.167.1491919087108; Tue, 11 Apr 2017 06:58:07 -0700 (PDT)
Subject:	Re: Use a default path in exec*p*() if PATH is unset?
To:	cygwin AT cygwin DOT com
References:	<d1bc1cea-2438-5e03-e84c-8d4e169d9592 AT t-online DOT de> <ae107c01-bea2-b562-1bc6-f5ba188eeba9 AT towo DOT net> <7b94712a-465d-421b-bc76-720e443708d3 AT t-online DOT de>
From:	cyg Simple <cygsimple AT gmail DOT com>
Message-ID:	<6991638b-2400-dacd-28ee-e2d2c9d91ed4@gmail.com>
Date:	Tue, 11 Apr 2017 09:58:09 -0400
User-Agent:	Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version:	1.0
In-Reply-To:	<7b94712a-465d-421b-bc76-720e443708d3@t-online.de>
X-IsSubscribed:	yes

On 4/11/2017 7:10 AM, Christian Franke wrote:
> Thomas Wolff wrote:
>> Am 10.04.2017 um 22:29 schrieb Christian Franke:
>>> A few years after https://cygwin.com/ml/cygwin/2014-09/msg00204.html
>>> I found another use case of an unset PATH variable:
>>>
>>> The configure script from mandoc (http://mdocml.bsd.lv/) uses this
>>> interesting approach to query default CC command from make:
>>>
>>> CC=`printf "all:\\n\\t AT echo \\\$(CC)\\n" | env -i make -sf -`
>> Why does it `env -i` at all?
> 
> I guess because make result should not depend on environment. I agree
> that 'env -i' is probably to much, 'env -u CC' would be enough.
> 

  -i, --ignore-environment  start with an empty environment

A relative use of the executable will not be found if the environment is
empty.

> 
>> (And why does it prepend a \ to the output?)
> 
> It doesn't. The extra \\ is required because `...` is used instead of
> $(...):
> 
> $ printf "all:\\n\\t AT echo \\\$(CC)\\n"
> all:
>         @echo \$(CC)
> 
> $ CC=$(printf "all:\\n\\t AT echo \\\$(CC)\\n" > /dev/tty)
> all:
>         @echo \$(CC)
> 
> $ CC=`printf "all:\\n\\t AT echo \\\$(CC)\\n" > /dev/tty`
> all:
>         @echo $(CC)
> 
> 
>> It seems this scriptlet has an issue, rather than adapting core
>> behaviour for it.
> 
> Of course Cygwin shouldn't be adapted solely for this single case.
> But it possibly Cygwin should be adapted to the existing practice of
> various other open source *ix systems.
> 

No, the other open source systems should adapt practices to defined
POSIX representation and not impose such "defaults" to their methods.
Using default behavior should never condoned as a default behavior,
unless defined explicitly can always be different elsewhere or even
change on the same system.

> Interestingly the approach in newlib/libc/posix/execvp.c differs from
> Cygwin and others:
> execvp() with PATH unset calls execv(). This has the same effect as
> execvp() with PATH set to current directory only.
> 

Why do you assume that this is an issue with execvp?  The user should
not expect that an undefined behavior behaves the same way on other
systems.  You might be able to get away with "env -i `which make` -sf -"
but this is broken based on POSIX.

-- 
cyg Simple

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -