JavaScript putenv
Set the value of an environment variable
1 2 3 4 56 7 8 9 1011 12 13 14 1516 17 18 19 | function putenv (setting) { // Set the value of an environment variable // // version: 1109.2015 // discuss at: http://phpjs.org/functions/putenv // + original by: Brett Zamir (http://brett-zamir.me) // % note 1: We are not using $_ENV as in PHP, you could define // % note 1: "$_ENV = this.php_js.ENV;" and get/set accordingly // % note 2: Uses global: php_js to store environment info // * example 1: putenv('LC_ALL=en-US'); // * results 1: true // BEGIN REDUNDANT this.php_js = this.php_js || {}; this.php_js.ENV = this.php_js.ENV || {}; // END REDUNDANT var pos = setting.indexOf('='); this.php_js.ENV[setting.slice(0, pos)] = setting.slice(pos + 1); return true; } |
Examples
Running
1 | putenv('LC_ALL=en-US'); |
Should result in
1 | true |
Dependencies
No dependencies, you can use this function standalone.
Open syntax issues
php.js uses JsLint to help us keep our code consistent and prevent some common bugs.
Eventually we want all code to pass or at least take into consideration most fixes suggested by JsLint, following this JsLint configuration we’ve decided on.
Authors
Thanks to the following developers, you get to have putenv goodness in JavaScript.
Kevin van Zonneveld
4 Sep '09 
If I was only creating the functions I needed. This site would have 6.
But looking at the site's stats, apparently there are many people out there that use many more.
You also have to think about people using these functions in non-browser environments like node.js & rhino.
Anyway. My point is: who are we to decide who is to use what. So it's a lot easier for us to just go ahead & port everything, and let the user decide what to pick.
Remember. You can compile your own packages.
Brett Zamir
30 Aug '09
Is it silly to have an environment variable or putenv() function in PHP? If you think so, fine, but we are just letting our users decide what aspects they wish to port over.
And I see no intrinsic difference between needing an environmental variable in PHP and one in JavaScript especially with uses of JavaScript going beyond far beyond client-side HTML only (and our adding it in JavaScript is hardly adding much overhead nor is it a black box); this function can be made to work with other functions, as setlocale() already does--it's not just making an environmental variable that does absolutely nothing.
And no one is compelling anyone to use a function they don't want to, nor is this function even a part of the default package... I fail to see how one not-so-useful function (if this even is one) is affecting the rest of the library. I'd understand if you were talking about something like phpcredits() (we have that under experimental for the heck of it--sometimes one just does something "for the heck of it", you know--call it art, boredom or whatever), but this does actually have a potential use.
If the PHP community feels it warranted to deprecate some items, we have moved such functions into our experimental section. Otherwise, there's nothing that makes me want to scream more (and thus I don't want to be someone who does this to others) than developers who confidently make abrupt decisions for everyone as far as what aspects of an already well-established API are "good" and which are not, and thereby limiting my and everyone else's creative choices. Let me as a user decide which is good and which is not, unless it really is a practice which is really likely to harm me (e.g., register globals) or encourage me to really make a big mess of things (e.g., an unfettered goto).
I hope my tone is not harsh when I say this (and this is not my library anyways), but I don't care so much about what the "cool crowd" is doing and would rather have fun and do what is convenient or interesting for myself and others--letting a rationale, constructive, and friendly dialog decide this rather than a dogma-by-silent-consensus and fear of going against the grain masquerading itself as "best practice". One can learn a lot more by seeing through one's own eyes in avoiding fears of what others think (and that is another stated purpose of Kevin's library--for students)--something which is helped along by a supportive atmosphere such as Kevin has engendered...
Some poorly implemented functions, on the other hand, could definitely, if unfairly, ruin the impression of the library for some (one reason we really need to get more tests in place and debug older functions), but this is, I think, a wholly different issue. If someone is so afraid of what others think that they will let one "silly" but accurate port cause them to forgo choosing from 400-500 other potentially useful and independent functions, then that is just, imho, a loss for them.
But feel free to contradict me if you can offer some concrete reasons that I've missed...
موبيلات و جوالات
Mar 22nd