This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
Cloud Ninja's profile picture

Overwrite all functions in a stock API at once?

Started by Cloud Ninja, 21 February 2016 - 04:19 PM
Cloud Ninja #1
Posted 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


for k,v in pairs(fs) do
  vBackup = v
  function v()
	  v = vBackup
	  --Whatever i want to do here---
	  return v()
    end
end
KingofGamesYami #2
Posted 21 February 2016 - 08:30 PM

for k, v in pairs(fs) do
  local b = v
  fs[k] = function( ... ) return b( ... ) end
end
Cloud Ninja #3
Posted 21 February 2016 - 11:49 PM

for k, v in pairs(fs) do
  local b = v
  fs[k] = function( ... ) return b( ... ) end
end
Thanks Yami!
Cloud Ninja #4
Posted 22 February 2016 - 01:07 AM

for k, v in pairs(fs) do
  local b = v
  fs[k] = function( ... ) return b( ... ) end
end
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.
Bomb Bloke #5
Posted 22 February 2016 - 03:01 AM
Why not load stick a copy of checkSU() into the sandboxed environment table, instead of into _G?
Cloud Ninja #6
Posted 22 February 2016 - 03:06 AM
Why not load stick a copy of checkSU() into the sandboxed environment table, instead of into _G?
I'm sorry, i dont understand this. What do you mean?
Bomb Bloke #7
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.
Cloud Ninja #8
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?
Sewbacca #9
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.
Bomb Bloke #10
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.
Cloud Ninja #11
Posted 23 February 2016 - 01:34 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.
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.
Bomb Bloke #12
Posted 23 February 2016 - 01:37 AM
have your sandboxes autorun a certain script file when they start, and have that handle it.