for k,v in pairs(fs) do
vBackup = v
function v()
v = vBackup
--Whatever i want to do here---
return v()
end
end
This is a read-only snapshot of the ComputerCraft forums,
taken in April 2020.
Overwrite all functions in a stock API at once?
Started by Cloud Ninja, 21 February 2016 - 04:19 PMPosted 21 February 2016 - 05:19 PM
I'm writing an SU API for my root method TKO for the operating system O, and I'm trying to overwrite all FS functions in batch. Is there a way i can do something like
Posted 21 February 2016 - 08:30 PM
for k, v in pairs(fs) do
local b = v
fs[k] = function( ... ) return b( ... ) end
end
Posted 21 February 2016 - 11:49 PM
Thanks Yami!for k, v in pairs(fs) do local b = v fs[k] = function( ... ) return b( ... ) end end
Posted 22 February 2016 - 01:07 AM
This worked, but i also need one more thing. I need to pass shell.getRunningProgram into an api, but i dont want the person to be able to put any program in, so i want no interaction other than checkSU(), and then in the code it checks with shell.getRunningProgram, but shell doesnt work in apis so i need some form of workaround.for k, v in pairs(fs) do local b = v fs[k] = function( ... ) return b( ... ) end end
Posted 22 February 2016 - 03:01 AM
Why not load stick a copy of checkSU() into the sandboxed environment table, instead of into _G?
Posted 22 February 2016 - 03:06 AM
I'm sorry, i dont understand this. What do you mean?Why not load stick a copy of checkSU() into the sandboxed environment table, instead of into _G?
Posted 22 February 2016 - 08:28 AM
The shell API isn't loaded into _G, but rather into the environment table of the shell which "loaded" it (that is to say, the shell script simply defines a global shell table and starts sticking functions into it).
This means regular APIs can't touch it (and with good reason - given that a system can run multiple instances of shell at once, which one should they try to interact with?).
So I'm suggesting you do the same: stick a pointer to your checkSU() function into the environment table for your sandbox. Since the shell table's also in there they'll be able to play with each other.
This means regular APIs can't touch it (and with good reason - given that a system can run multiple instances of shell at once, which one should they try to interact with?).
So I'm suggesting you do the same: stick a pointer to your checkSU() function into the environment table for your sandbox. Since the shell table's also in there they'll be able to play with each other.
Posted 22 February 2016 - 11:23 AM
So do something like ' local SU = {} ' and then throw functions in there? How would i go about doing so and allowing anything to execute those functions?
Posted 22 February 2016 - 06:26 PM
So do something like ' local SU = {} ' and then throw functions in there? How would i go about doing so and allowing anything to execute those functions?
I think, you have to deny all other functions with setfenv(func, env), but it will be removed in CC 2.0. You will have to use _ENV.
Posted 23 February 2016 - 12:53 AM
So do something like ' local SU = {} ' and then throw functions in there? How would i go about doing so and allowing anything to execute those functions?
Have a think about how shell does it. That is to say, have your sandboxes autorun a certain script file when they start, and have that handle it.
Posted 23 February 2016 - 01:34 AM
I dont know how shell does it, thats my issue. I havn't messed with too much heavy sandboxing or environments too much other than _G getfenv() hacking back in 1.73 and before.So do something like ' local SU = {} ' and then throw functions in there? How would i go about doing so and allowing anything to execute those functions?
Have a think about how shell does it. That is to say, have your sandboxes autorun a certain script file when they start, and have that handle it.
Posted 23 February 2016 - 01:37 AM
have your sandboxes autorun a certain script file when they start, and have that handle it.