Eric Blake wrote on 2009-11-17:
> unsetenv(name) only cleared the first instance, even if (ab)use of
> putenv, or assignment to environ, included duplicates of name.
>
> * m4/setenv.m4 (gl_FUNC_UNSETENV): Check for bug.
> * lib/unsetenv.c (rpl_unsetenv): Work around it.
I'm adding doc about this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 11/17/2009 2:45 AM:
>> I'll test on a few more platforms, then push.
>
> test-unsetenv is failing on Solaris 10:
Well, you obviously spotted a platform I missed in re-testing. ;)
> The above makes me wonder if Solaris 10
Eric Blake wrote:
> Coreutils got recent reports of a FreeBSD failure on 'env -u a=b', which
> should
> fail because unsetenv should reject invalid environment variable names (kind
> of
> obvious, though, when you realize BSD unsetenv returns void instead of int,
> contrary to the POSIX signature
Eric Blake wrote:
> According to Eric Blake on 11/16/2009 11:01 AM:
>> Coreutils got recent reports of a FreeBSD failure on 'env -u a=b', which
>> should
>> fail because unsetenv should reject invalid environment variable names (kind
>> of
>> obvious, though, when you realize BSD unsetenv returns
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 11/16/2009 11:01 AM:
> Coreutils got recent reports of a FreeBSD failure on 'env -u a=b', which
> should
> fail because unsetenv should reject invalid environment variable names (kind
> of
> obvious, though, when you real
Coreutils got recent reports of a FreeBSD failure on 'env -u a=b', which should
fail because unsetenv should reject invalid environment variable names (kind of
obvious, though, when you realize BSD unsetenv returns void instead of int,
contrary to the POSIX signature). I think this should fix i
