Use a default path in exec*p*() if PATH is unset?

Use a default path in exec*p*() if PATH is unset?

[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@echo \\\$(CC)\\n" | env -i make -sf -`

This works at least on Linux, (Free|Net|Open)BSD and OpenIndiana. It 
fails on Cygwin because 'env -i' unsets everything and execvp() does not 
use a default path then. This is OK from the POSIX 
("implementation-defined") point of view but differs from existing practice.

At least some Linux distros use ".:/bin:/usr/bin" as default path 
(https://linux.die.net/man/3/exec). Including the current directory is 
IMO a bad idea.

This is apparently inherited from the early days:
The current directory is included on current Debian stable, and
[... time travel ...]
also
[... time travel ...]
on Slackware 1.0.1 from 1993 :-)
(Thanks to http://www.qemu-advent-calendar.org/2014/ for this image)

Other OS typically use a default path without current directory.

Should Cygwin also use a default path, for example _PATH_DEFPATH=/bin ?

Christian


--
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

Re: Use a default path in exec*p*() if PATH is unset?

[Thomas Wolff]

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@echo \\\$(CC)\\n" | env -i make -sf -`
Why does it `env -i` at all? (And why does it prepend a \ to the output?)
It seems this scriptlet has an issue, rather than adapting core 
behaviour for it.
Thomas

--
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

Re: Use a default path in exec*p*() if PATH is unset?

[Christian Franke]

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@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.


> (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@echo \\\$(CC)\\n"
all:
         @echo \$(CC)

$ CC=$(printf "all:\\n\\t@echo \\\$(CC)\\n" > /dev/tty)
all:
         @echo \$(CC)

$ CC=`printf "all:\\n\\t@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.

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.

Christian


--
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

Re: Use a default path in exec*p*() if PATH is unset?

[cyg Simple]

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@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@echo \\\$(CC)\\n"
> all:
>         @echo \$(CC)
> 
> $ CC=$(printf "all:\\n\\t@echo \\\$(CC)\\n" > /dev/tty)
> all:
>         @echo \$(CC)
> 
> $ CC=`printf "all:\\n\\t@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

Re: Use a default path in exec*p*() if PATH is unset?

[Christian Franke]

cyg Simple wrote:
>
>    -i, --ignore-environment  start with an empty environment
>
> A relative use of the executable will not be found if the environment is
> empty.

Not necessarily (see Linux, *BSD, ...). POSIX says this is 
"implementation-defined" - under the assumption that 'env' uses execvp() 
which is the case for the GNU coreutils version.


>> 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?

I never did (otherwise this would be a thread on cygwin-patches list).

The above only means that it is IMO interesting that the Cygwin source 
package contains two implementations of execvp() which handle the unset 
PATH situation differently.


> The user should
> not expect that an undefined behavior behaves the same way on other
> systems.

Of course. But even then it is a reasonable question which possible 
alternative should be implemented by Cygwin. Cygwin homepage says "Get 
that Linux feeling, ...". So "implementation-defined" behavior should 
possibly be close to Linux :-)

Christian


--
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

Re: Use a default path in exec*p*() if PATH is unset?

[cyg Simple]

On 4/11/2017 3:02 PM, Christian Franke wrote:
> cyg Simple wrote:
>>
>>    -i, --ignore-environment  start with an empty environment
>>
>> A relative use of the executable will not be found if the environment is
>> empty.
> 
> Not necessarily (see Linux, *BSD, ...). POSIX says this is
> "implementation-defined" - under the assumption that 'env' uses execvp()
> which is the case for the GNU coreutils version.
> 

> POSIX says this is "implementation-defined"

Which means it is undefined by POSIX.  Also one could argue that
--ignore-environment also means any default ones within an API set.

> 
>>> 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?
> 
> I never did (otherwise this would be a thread on cygwin-patches list).
> 
> The above only means that it is IMO interesting that the Cygwin source
> package contains two implementations of execvp() which handle the unset
> PATH situation differently.
> 

Sure, but it is implemented correctly based on POSIX. ;)

> 
>> The user should
>> not expect that an undefined behavior behaves the same way on other
>> systems.
> 
> Of course. But even then it is a reasonable question which possible
> alternative should be implemented by Cygwin. Cygwin homepage says "Get
> that Linux feeling, ...". So "implementation-defined" behavior should
> possibly be close to Linux :-)
> 

Even so not all "Linux feeling" can be implemented.  But I agree it
should be as close as possible.

But I don't believe that env --ignore-environment should be using execvp
and should be using execv instead.  That is for the upstream coreutils
team to decide though.

-- 
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

Re: Use a default path in exec*p*() if PATH is unset?

[Christian Franke]

cyg Simple wrote:
> ...
> But I don't believe that env --ignore-environment should be using execvp
> and should be using execv instead.  That is for the upstream coreutils
> team to decide though.

Possibly not, as it would also require to check whether PATH is set 
later in the command line.

Always using execv() if -i is specified would break:

   env -i PATH=/bin:/usr/bin prog

To force execv()-like behavior with -i, simply use

   env -i PATH=. prog


Christian


--
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

Re: Use a default path in exec*p*() if PATH is unset?

[cyg Simple]

On 4/12/2017 12:41 PM, Christian Franke wrote:
> cyg Simple wrote:
>> ...
>> But I don't believe that env --ignore-environment should be using execvp
>> and should be using execv instead.  That is for the upstream coreutils
>> team to decide though.
> 
> Possibly not, as it would also require to check whether PATH is set
> later in the command line.
> 
> Always using execv() if -i is specified would break:
> 
>   env -i PATH=/bin:/usr/bin prog
> 

Good!  --ignore-environment is just that regardless of where the
environment is set.

> To force execv()-like behavior with -i, simply use
> 
>   env -i PATH=. prog
> 

But this is what should occur anyway.

-- 
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