I've never noticed this before, but your post poked my curiousity, so I looked into it.

I can't explain what that environment variable is for, But I think I can explain why you are getting that in your logs.

According to some results i found when searching for "invalid character" and "exportstr", bash (or at least some versions of bash) will not allow you to have certain characters in the names of environment variables. if you try to set/export an variable with an invalid cahracter, you get a message like the one you posted (32 is SPACE)

I haven't been able to confirm this (because my version of bash doesn't seem to mind env variables with spaces in them) but i believe on the box you found this error:

1. sh is a symlink to bash
2. perl -le '%ENV=("foo bar" => 1); print `env`;' should produce a similar warning.

The issue being that in perl you can happily set an environment variable with a space in the name (because it's just a hash) but when you go to exec a process (using sh, which is just bash) bash rejects that variable.

Sooooooo...

Based on the location of that my_setenv in perl.c, it looks like it only gets used when perl is embeded, and since you mentioned it was in your apache log, i would guess you are using mod_perl -- so my hunch is: you have a mod_perl script/handler which uses either backticks or system() to invoke an external app. When that happens, bash is complaining about this environment varaible.

All I have to say is "holy crap"! ++ for hossman!

thor

Feel the white light, the light within
Be your own disciple, fan the sparks of will
For all of us waiting, your kingdom will come

I can't replicate this:

cantrelld@c0025:~$ ls -l `which sh`
lrwxrwxrwx  1 root root 4 Nov 17 09:54 /bin/sh -> bash

cantrelld@c0025:~$ perl -le '%ENV=("foo bar" => 1); print `env`;'
foo bar=1

cantrelld@c0025:~$ perl -v

This is perl, v5.8.4 built for i386-linux-thread-multi
[download]

Neither can I. As I said...

I haven't been able to confirm this (because my version of bash doesn't seem to mind env variables with spaces in them)

The question is: which version of bash do you have, and which version does saintmike have; if they are the same, then I'm probably wrong.

Another little tidbit.

A quick little binary search grep of past perl distributions (god bless the "tools" link on search.cpan.org) indicates that the relevent line from perl.c (my_setenv("NoNe  SuCh", Nullch);) was initially in mg.c, and first appeared in perl5.004_01.

Changes indicates the following changes below involving mg.c, ...unfortunately I don't know enough about perforce to pull out individual diffs and figure out exactly which commit message corrisponds to that line, so I still don't understand what it's for...

hossman wrote "A quick little binary search grep of past perl distributions (god bless the "tools" link on search.cpan.org)....."

What "tools" link? Where do you grep on past perl distributions? That seems like a useful thing to be able to do!

Go to a release of perl (or any module, for that matter). For instance, here's perl 5.8.6. Look for the Links part of heading for the release. Check out that last link entitled "Tools". Enjoy.

--
edan

From some unknown version of mod_perl:

my_setenv("NoNe  SuCh", Nullch);
/* force copy of environment */
...
[download]

I suspected it might be related to forking. This seems to confirm it. When forking, the parent and child processes share memory pages until one writes to them. I don't know why one would need to force the one containing the environment to become unshared.

Have you tried asking on the mod_perl mailing list? If you compiled your own mod_perl, you could simply change "NoNe SuCh" to "NoNeSuCh" and recompile it.

Perhaps mod_perl needs to be patched then, either to remove the space, or to leave the my_setenv() call as it is but immediately follow it with an unsetenv().