[roland/env-only] Avoid re-exec-self in bug-setlocale1.

  This extends the makefile infrastructure for tests to use a variable
<testname>-ENV-only that is like the existing <testname>-ENV but for
cases where the test program should run with a completely bare
environment except for the explicit assignments in the makefile.
This lets us get rid of the use of execve in bug-setlocale1 (and any
similar cases I have not yet noticed).

Unless there are objections, I'll commit this by Thursday.


Thanks,
Roland



2015-03-04  Roland McGrath  <roland@hack.frob.com>

	* Makeconfig (test-wrapper-env-only): New variable.
	* Rules (make-test-out): If variable $*-ENV-only is nonempty,
	then use that with $(test-wrapper-env-only) rather than using
	$(test-wrapper-env) $(run-program-env) $($*-ENV).

localedata/
2015-03-04  Roland McGrath  <roland@hack.frob.com>

	* bug-setlocale1.c (do_test): Remove argument handling and
	self-exec'ing logic.  Just expect to be run with the right
	variables (and nothing else) directly in the environment instead.
	(TEST_FUNCTION): Don't pass arguments to do_test.
	* Makefile (bug-setlocale1-ARGS, bug-setlocale1-static-ARGS):
	Variables removed.
	(bug-setlocale1-ENV-only, bug-setlocale1-static-ENV-only):
	New variables.
  

On 03/04/2015 10:23 PM, Roland McGrath wrote:
> This extends the makefile infrastructure for tests to use a variable
> <testname>-ENV-only that is like the existing <testname>-ENV but for
> cases where the test program should run with a completely bare
> environment except for the explicit assignments in the makefile.
> This lets us get rid of the use of execve in bug-setlocale1 (and any
> similar cases I have not yet noticed).

Some things break if you run them with certain locale settings, so some
tests lack this environment isolation.

I wanted to sanitize the environment more thoroughly, for all tests:

  <https://sourceware.org/ml/libc-alpha/2014-09/msg00100.html>

I haven't implemented the env -u suggestion yet.
  

On 04 Mar 2015 13:23, Roland McGrath wrote:
> This extends the makefile infrastructure for tests to use a variable
> <testname>-ENV-only that is like the existing <testname>-ENV but for
> cases where the test program should run with a completely bare
> environment except for the explicit assignments in the makefile.
> This lets us get rid of the use of execve in bug-setlocale1 (and any
> similar cases I have not yet noticed).

lgtm
-mike
  

I suspect that where we want to get to is that all tests run with a
completely controlled environment.  I can't really think of any reason why
any of our tests should be run with random ambient environment variables.
But I'm starting small.
  

On 03/05/2015 05:18 PM, Roland McGrath wrote:
> I suspect that where we want to get to is that all tests run with a
> completely controlled environment.  I can't really think of any reason why
> any of our tests should be run with random ambient environment variables.
> But I'm starting small.

Agreed.

Cheers,
Carlos.
  

On Wed, 4 Mar 2015, Roland McGrath wrote:

>  ifndef test-wrapper-env
>  test-wrapper-env = $(test-wrapper) env
>  endif
> +# Likewise, but the program's environment will be empty except for any
> +# explicit <variable>=<value> assignments preceding the program name.
> +ifndef test-wrapper-env-only
> +test-wrapper-env-only = $(test-wrapper) env -i
> +endif

Needs documenting in install.texi / INSTALL, where it describes how 
test-wrapper-env must be set if $(test-wrapper) env isn't sufficient.
  

On Thu, 5 Mar 2015, Roland McGrath wrote:

> I suspect that where we want to get to is that all tests run with a
> completely controlled environment.  I can't really think of any reason why
> any of our tests should be run with random ambient environment variables.
> But I'm starting small.

Test scripts run on the build system certainly need variables such as PATH 
to find utilities.

It may be that all test programs run on glibc's host never need to execute 
any external utilities, so don't need PATH.  Some tests may create 
temporary files in TMPDIR, though use of /tmp should be fine as long as 
they use unique names (and if they don't, this needs fixing - bug 13888).  
Some tests (e.g. glob expanding ~) depend on HOME, but setting values 
local to the test directory may work.  Those seem the most likely 
environment variable dependencies for tests.
  

> Test scripts run on the build system certainly need variables such as PATH 
> to find utilities.

Sure.  Entirely controlled doesn't mean entirely empty.
  

On 06 Mar 2015 18:52, Joseph Myers wrote:
> On Thu, 5 Mar 2015, Roland McGrath wrote:
> > I suspect that where we want to get to is that all tests run with a
> > completely controlled environment.  I can't really think of any reason why
> > any of our tests should be run with random ambient environment variables.
> > But I'm starting small.
> 
> Test scripts run on the build system certainly need variables such as PATH 
> to find utilities.
> 
> It may be that all test programs run on glibc's host never need to execute 
> any external utilities, so don't need PATH.  Some tests may create 
> temporary files in TMPDIR, though use of /tmp should be fine as long as 
> they use unique names (and if they don't, this needs fixing - bug 13888).  
> Some tests (e.g. glob expanding ~) depend on HOME, but setting values 
> local to the test directory may work.  Those seem the most likely 
> environment variable dependencies for tests.

wrt TMPDIR, it would be nice if the test runner managed a tempdir for the test.  
that way we don't have to worry:
 - whether the test properly cleans up after itself on exit/crash/interrupt;
   we can just assume it's always done for us and thus not have to even try
 - are we using the TMPDIR securely

this could be done to a degree in the test-skeleton
-mike