How can I set an environment variable in WSH jscript file that calls another program? Here's the reduced test case:
envtest.js
----------
var oShell = WScript.CreateObject("WScript.Shell");
var oSysEnv = oShell.Environment("SYSTEM");
oSysEnv("TEST_ENV_VAR") = "TEST_VALUE";
oExec = oShell.Run("envtest.bat", 1, true);
envtest.bat
-----------
set
pause
I expect to see TEST_ ENV _VAR in the list of variables, but it's not there. What's wrong?
edit:
If someone can produce a working code sample, I'll mark that as the correct answer. :)
The problem is not in your code, but it is in execution of the process. The complete system variables are assigned to the process which is executed. so, your child process also had the same set of variables.
Your code-sample works good. It adds the variable to the SYSTEM environment.
So, you need to set the variable not only for your system but also for your process.
Here's the code.
var oShell = WScript.CreateObject("WScript.Shell");
var oSysEnv = oShell.Environment("SYSTEM");
oSysEnv("TEST1") = "TEST_VALUE";
var oSysEnv = oShell.Environment("PROCESS");
oSysEnv("TEST1") = "TEST_VALUE";
oExec = oShell.Run("envtest.bat", 1, true);
Once you created the system variable.
It will assign the newly created variable for the current process. So, your child process can get that variable while the "SET" command executed.
Sorry for my bad-english.
There are 4 "collections" (System, User, Volatile, and Process) you probably want Process if you just need a child process to see the variable
You are getting the system environment variables. I suspect you simply don't have permission to modify them; you could try changing this to the user environment variables.
Also I don't know whether the argument to Environment() is case-sensitive or not. MS's documentation uses "System" instead of "SYSTEM". Might make a difference but I don't know for sure.
Related
(This is probably a very silly question since I'm just beginning with nodejs, nevertheless I can't understand how this works. Let me know what is missing in my question, I'll correct.)
I'm trying to use the npm package likely.
in my server.js file I have thus written this
var Recommender = require('likely');
in likely.js you can find variables like these:
var DESCENT_STEPS = 5000; // number of iterations to execute gradient descent
var ALPHA = 0.0005; // learning rate, should be small
I would like to modify these variables inside my server.js file.
I believe the way to do that is adding this after the require()
Recommender.DESCENT_STEPS = 9999999999;
but that doesn't seem to change the value that is defined in likely.js and that is actually used by the model. (by running the model I can see it doesn't work since so much steps should take forever and the processing time doesn't change at all)
Can I only do this by modifying likely.js?
You cannot modify them programmatically because likely.js only uses the local variable values instead of the current value of the exported versions of the same variables. So if you wanted to change those values you currently would need to edit likely.js. You might want to submit a pull request to that project's repository that makes the code use the exported value (e.g. module.exports.DESCENT_STEPS) instead.
You need to publicize these variables to be viewable by server.js.
var object = {
DESCENT_STEPS = 5000;
ALPHA = 0.0005;
}
module.exports = object;
Now it can be viewed and modified in server.js.
Recommender.ALPHA = 'new value';
I'm creating a plugin system using the following:
function Plugin(thingy, code)
{
var GLOBAL = null;
var arguments = null;
var process = null;
var require = null;
eval(code);
};
plugins.push(new Plugin(thingy, code));
Please don't get too excited about the eval(), using ('vm') or a sandbox is not an option as this will be a long running object until the user unloads it. It will also be running in it's own nodeJS instance so they can't affect other users. I'd still have the same problem passing in this object reference to a sandbox system anyway.
What I am concerned about is someone seeing the code of the thingy object that has functions they need to use e.g shoot()
console.log(thingy.shoot.toString());
A way around this was the following:
function thingy()
{
// They can't see this
var _shoot = function(someone)
{
// Load weapon
// Aim
// Fire
};
// They can see this
this.shoot = function(someone)
{
_shoot(someone);
};
};
This way if they console.log(thingy.shoot.toString()) they'll only see _shoot(someone); and not the actual code that handles the shooting process.
Please could someone help me with the following:
Is there an easier way to limit access to a passed in variables code?
I'm setting GLOBAL, arguments, process and require to null; are there others I need to worry about?
I want to do the following:
execute a Javascript file with v8
open a REPL which evaluates code in the exact same context as the code
Any variables or functions defined in the code file, for instance, should be available in the REPL. (I'll note this used to work many v8 versions ago, but I can't figure out how to get it working in current v8 (node 0.12 == v8 3.28.73).)
I use a simple class JSInterpreter which has an isolate and a persistent context object as member vars. They gets set up when the class is initialized, and bindings also happen at that time.
When it's time to interpret some code, I call this method:
Str JSInterpreter::InterpretJS (const Str &js)
{ v8::Isolate::Scope isolate_scope (isolate_);
v8::HandleScope handle_scope (isolate_);
// Restore the context established at init time;
// Have to make local version of persistent handle
v8::Local <v8::Context> context =
v8::Local <v8::Context>::New (isolate_, context_);
Context::Scope context_scope (context);
Handle <String> source = String::NewFromUtf8 (isolate_, js . utf8 ());
Handle <Script> script = Script::Compile (source);
Handle <Value> result = script -> Run ();
I want to call this method over & over again, and each time, I want the context to contain any accumulated state from earlier calls. So if the code file contains (only) var x = 5; at the REPL I should be able to type > x and see the result 5.
But the actual result is x is not defined.
It turns out that this code actually does work as expected. The problem was that I was using browserify before running the code, and the code (e.g. var x = 5;) was getting wrapped into a function scope.
I have written my code across several files for my node server.
If I have a file, say basket.js:
var Basket = {
fruits : 0,
addFruit : function() {
fruits++;
},
removeFruit : function() {
fruits--;
},
printFruit : function() {
console.log(this.fruits);
}
}
module.export = Basket;
And I have another file called give.js:
var Basket1 = require("./basket.js");
Basket1.addFruit();
Basket1.printFruit();
And another file called take.js:
var Basket2 = require("./basket.js");
Basket2.removeFruit();
Basket2.printFruit();
Will both files write into the same instance of Basket?
In other words, will they both have control over the property, fruits?
Does node manage race conditions on its own? i.e. if two commands to modify fruit come in at the same time from add and sub, does node know how to handle it?
If I want to make a way in which two files can look at a singleton at the same time and access it, is this the way to go?? Or how else does one do it?
Yes, they will access the same object.
Modules are cached after the first time they are loaded. This means (among other things) that every call to require('foo') will get exactly the same object returned, if it would resolve to the same file.
– Modules docs
No, node does not manage race conditions on its own, because race conditions will not be caused by node itself. Node is single-threaded and thus no code can be executed at the same time as other code. See for example this answer for some more explanation.
I'm a beginner but I think the correct syntax is module.exports not modules.export - if you may correct so that people don't wonder why it does not work like I just did :)
In JavaScript when i say window.SomeData = 'whatever', where does it get saved in the browser? I thought it gets saved in the viewstate but it doesnt. Also how much security concern is it to save some data in window.someKey. I am not talking about username or password storage but some general data like PK values of some records.
--Edit--
The reason i am asking this is because i have a page with 5 tabs and each tabs gets loaded by an AJAX call. I need to save the data that comes back from AJAX request and currently i am using window.somekey to save it.
It gets saved in the global object window. That object is not very secure and its lifetime is for that page.
It doesn't get saved anywhere, it is exactly the same as using a global variable:
var SomeData = "whatever"; //done in global scope obviously
window.SomeData === "whatever" //true
Nowhere, effectively. Data stored in random fields of the window object is not saved.
The annoying answer is its saved in memory! Its no different than having
var j = {}
j.SomeData = 'Whatever'
window is just a global variable containing all the information about window (such as the documents DOM)
window can have data saved like the j variable above. Its no less safe than saving any piece of information ANYWHERE else in js. The only risk you have is that the items namespace may be used by another library.
So if i were you i would do this. (use this as a guide to writing good JS http://enterprisejquery.com/2010/10/how-good-c-habits-can-encourage-bad-javascript-habits-part-1/)
(function(MyLibrary, $, undefined) {
var stuff;
MyLibrary.SomeData = 5;
}(window.MyLibrary = window.MyLibrary || {}, jQuery)); // or moo tools
alert(window.MyLibrary.SomeData); // 5!
It's generally good practice to use an object as namespace for functions and variables specific for web application. For example:
var site = {};
site.someData = 'whatever';
site.initGallery = function() {
//
};
Declaration of variables in global namespace (in client-side JS, window is global namespace) is called global-namespace pollution and is generally undesirable and unrecommended since it can lead to naming conflicts either with other libraries that also pollute global namespace or, even worse, with browser's native global objects.