DragonFlyBSD

:After the recent libc changes, we no more allow environmental variables to =
:have
:an '=3D' character in their name. The printenv(1) utility isn't aware of th=
:at, so
:it embarrasses itself, along with misleading the user:
:..
:
:What do you think ? Ship it ?
:
:Cheers,
:Stathis

No, it definitely should not exit if it is asked to display an
    environment variable with '=' in it.  It could print a warning
    to stderr, though, but I don't think it's necessary.  If the
    environment variable isn't supposed to exist then it won't find
    it.  If the environment variable does exist it is not printenv's
    job to check whether it is legal or not.

-Matt

: If the environment variable isn't supposed to exist then it won't find it.
: If the environment variable does exist it is not printenv's job to check
: whether it is legal or not.

True, but printenv isn't very good at deciding if a variable exists in an
environment or not, in case the name contains an '='.

Here is an example. Let's say that there is a variable named "foo" that equals
"bar=123" and we ask from printenv to print the variable "foo=bar" (which
obviously doesn't exist). Here is what happens:

For every "name=value" pair inside the environment, printenv invokes a memcmp
between the currently examined variable and the target, of at most `len' bytes.
Where `len' is the length of the target. So, memcmp("foo=bar", "foo=bar=123", 7)
actually returns a match, although "foo=bar" doesn't correspond to a real variable.

I hope I didn't confuse things more.

Cheers,
Stathis

:Stathis Kamperis <ekamperi@gmail.com> added the comment:
:
:...
:ch
:obviously doesn't exist). Here is what happens:=20
:
:For every "name=3Dvalue" pair inside the environment, printenv invokes a me=
:mcmp
:between the currently examined variable and the target, of at most `len' by=
:tes.
:Where `len' is the length of the target. So, memcmp("foo=3Dbar", "foo=3Dbar=
:=3D123", 7)
:actually returns a match, although "foo=3Dbar" doesn't correspond to a real=
: variable.
:
:I hope I didn't confuse things more.
:
:Cheers,
:Stathis

It sounds to me that printenv's environment search is what needs to
   be fixed.  The environ has one environment variable per array entry.
   instead of doing the memcmp() it should iterate forwards looking for
   the first '=', then do a length check and, if the length matches,
   finally a memcmp().

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

: It sounds to me that printenv's environment search is what needs to
: be fixed. The environ has one environment variable per array entry.
: instead of doing the memcmp() it should iterate forwards looking for
: the first '=', then do a length check and, if the length matches,
: finally a memcmp().

They way you put it, seems more reasonable to me.
I attached a new diff.

Cheers,
Stathis

Wasn't this already commited? I remember seeing something about '='s in some env
function.

: Wasn't this already commited?
: I remember seeing something about '='s in some env function.

Hey alexh. That patch was about setenv(3), which is now fixed.
printenv(3) needs to be fixed as well.

Cheers,
Stathis

Oh, I'm sorry, I mixed those two up.
I'm renaming it if you don't mind so it is easier to see that there is a diff
already, to [PATCH]: ....

I am going to push this tomorrow or the day after, unless someone objects.

Just for the record, I have filed a PR in NetBSD bug database as well and they
fixed it differently:

...
if (argc != 1)
usage();
if (strchr(*argv, '=') != NULL)
errx(1, "Invalid environment variable %s", *argv);
len = strlen(*argv);
for (ep = environ; *ep; ep++)
...

POSIX says that env vars shouldn't contain an '=' sign and functions as
setenv(3) fail with EINVAL if the supplied name contains an equal sign.

Cheers,
Stathis