moving variables up

This is the main code which runs basicaly runs the shell program and constantly checks to see if 'microUserInput' is equil to "exit" and once it is, it exits. The problem here is that programs run in the new shell cannot modify the 'microUserInput' for some reason.

--Thanks to Grim Reaper for the following sandbox code!
function microShell()
local dir = fs.getDir(fs.getDir(shell.getRunningProgram())).."currentUser"
local oldFs = {}
local matches = {}
if not fs.isDir(dir) then
		fs.makeDir(dir)
		if not fs.isDir(dir) then
				printError("Could not initialize sandbox.")
				sleep(2)
	return false
		end
end
for name, func in pairs(_G.fs) do
  oldFs[name] = func
  if name ~= "combine" then
		_G.fs[name] = function(path, ...)
		  --path = shell.resolve(path)
		  if oldFs.isReadOnly(path) then
				return oldFs[name](path, ...)
		  end
   local a = 1
   for token in path:gmatch("[^/]+") do --iterate over any value that is NOT '|' (gmatch code []= custom pattern, ^=NOT |=delimiter we are using +=as many matches as possible)
	matches[a] = token
	a=a+1
   end
	if matches[1] ~= "rom" then
			path = dir .. "/" .. path
		 end
			return oldFs[name](path, ...)
	end
  end
end
term.setBackgroundColor(colors.black)
term.clear()
term.setCursorPos(1, 1)
shell.run("shell")
-- Restore fs api.
for name, func in pairs(oldFs) do
  _G.fs[name] = func
end
end
function microCheck()
while true do
  print("checking")
  print(microUserInput)
  if microUserInput == "exit" then
   print("accepted")
   sleep(2)
   error()
  end
  sleep(3)
end
end
parallel.waitForAny(microShell, microCheck)

microUserInput is never being set or changed, thus the if statement will never succeed.

Is there code we cannot see, or is this all the relevant lines?
If you want a program run by this program to have access to the variable, try storing microUserInput in the global space:

_G.microUserInput = ""

Any program that uses:

microUserInput = "exit"

should edit the global version and thus your script should work.

Using the global space is never really a good idea, but I am not really sure of any other ways short of returning from the program being run, which would stop the program.

Hbomb_79, on 27 July 2015 - 08:16 AM said:

Using the global space is never really a good idea, but I am not really sure of any other ways short of returning from the program being run, which would stop the program.

^ This is wrong. There are cases you should use the global env, and there are cases you should use the local env. It's only bad if you mix them up.

H4X0RZ, on 27 July 2015 - 08:48 AM said:

^ This is wrong. There are cases you should use the global env, and there are cases you should use the local env. It's only bad if you mix them up.

That is exactly what I was saying, thus why I said it is never a good idea. If you can avoid cluttering the global space, you should make an effort to. If there is a way to avoid it, then there is no point in stuffing it in there where it can be accessed via lua prompts and other programs.

So just to reiterate. If you can avoid using the global space, you should do so. At least, thats what I have been told, and continue to enforce in my own programming.

Thanks! this works well!

H4X0RZ, on 27 July 2015 - 08:48 AM said:

Hbomb_79, on 27 July 2015 - 08:16 AM said:

Using the global space is never really a good idea, but I am not really sure of any other ways short of returning from the program being run, which would stop the program.

^ This is wrong. There are cases you should use the global env, and there are cases you should use the local env. It's only bad if you mix them up.

Hbomb_79, on 27 July 2015 - 09:49 PM said:

So just to reiterate. If you can avoid using the global space, you should do so. At least, thats what I have been told, and continue to enforce in my own programming.

Well, you should make things local when you declare a variable, that is correct.
- Its faster (Not a ton, but in complicated scripts that many preform calculations it makes a difference)
- Other programs (or your program) won't accidentally use each others left over variables, assuming they are nil

Something like an OS would have to override things in the global environment, like the fs API for example to allow a for custom file protection system.
Which is perfectly fine. But its intentionally, the fact that it effects other programs isn't an accident.

Microwarrior, on 29 July 2015 - 01:21 AM said:

Thanks! this works well!

I am glad it worked for you!