A global variable is a variable that is accessible and modifiable at all times in all parts of the program with no particular access control, since the idea of "access control" wasn't even around at the time. C, Python, and Perl all have global variables. Despite your contention, Erlang and Haskell do not.
Mnesia, ETS, and DETS all control access via message passing; it's a common misconception but you never get direct access to an Mnesia table and with ETS I think you get a choice of "direct access in one process only" or "ETS spawns a process to manage the table" (not sure about DETS, but I guarantee it still won't be global). How could you even get direct access to a table that may be on another physical server? Mnesia has transactions for Pete's sake; how much less "no particular access control" can you get?! The closest thing to global variables you can get in Erlang is the process dictionary, which is still process-local. Erlang is probably the hardest language I know to have a true global in, because even if you cheat and have a C extension that has a C global in it, odds are that Erlang will still access it via an Erlang process wrapped around it which still has the effect of de facto locking the value into atomic reads and writes.
Haskell's State monad does not have anything remotely resembling a "global" value; it is explicitly scoped, labelled by the type system so that you can't cheat your way into it, and it literally desugars into threading functional values through a series of function calls. If that's a global variable, then you've devalued the term "global variable" to the point where every parameter of every function call is a global variable. The IO monad can contain a global value by the definition I gave above, if and only if you use "unsafePerformIO", which is an escape hatch that loudly proclaims "I AM LEAVING PURE FUNCTIONAL BEHIND AND I AM ASKING FOR THE RESULTING PAIN", and, indeed, leaves pure functional behind and asks for the resulting pain. So while that does allow you a global variable, if you really push it, it will actually end up very hard to use due to the difficult-to-predict order of evaluation and isn't a useful thing to do with unsafePerformIO. Otherwise, you only get access to the variable in IO-labeled functions, which except in pathological programs won't be anything like "all functions" and is certainly not globally available to everything. And you'll still need to do some major-league cheating to get access to even the "global" variables I mention here without passing explicit references to them all around; I'm still not sure that's possible without a C extension though I don't know enough to rule it out completely.
I can't argue for the other languages you mention since I don't know them.
Your argument is flawed, since you have some sort of weirdly potent definition of "global variable" that results in numerous things that aren't "global" getting called "global".