API / OS Hybrid

Alright, so I am writing an API for use with my accompanying OS. What I'd like to be able to do is: If the file is just in a directory on the computer and run as a program, it will run a separate function. However if it is called as an API [os.loadAPI()] then I would like it to be able to alternate between API mode and OS mode while still loaded as an API. I don't believe the os.loadAPI() accepts an argument other than the file to load so I would find this slightly more difficult, but here is the general format:

[some program calling the file as an api]

os.loadAPI("myApiOS", 0) –This will run in 'API MODE'
*some code that uses the api*

os.loadAPI("myApiOS", 1) –This will run in 'OS MODE'
*now we are running the OS from the API file, while still being able to call to the api*

[//END]

[just the API/OS file in a directory]]

*runs as if called with os.loadAPI("myApiOS", 1)

[//END]

Also, as I do not actively know of a way that this could be accomplished I would recommend this in the Suggestions for a future update, This would allow all new possibilities with APIs!

I have brainstormed on how I would accomplish this but have failed to get anything that wouldn't by default run the OS.

Any and all help is much appreciated!

Well, you could *kind of* distinguish between your file being run as a program, or being executed to load an API by seeing if the shell table is available. If it isn't, it's likely being loaded as an API.

The better question is, why do you even want to do this?

Well, I didn't want to have multiple files, see the OS is actually just a function that then references back into the api, so instead why not have it in the same file. Secondly since its an api that allows other people to use the os in the api as somewhat of a 'configuration shell' for the api. The os is truly an os, it uses the api to set other conditions and variables within the api to act as an active api modifier. So what I did was included it within the api so that if someone else runs the api they can set variables and conditions with there own code but I also have included a 'miny shell' that would allow them to set these via a command line. But obviously there could be far more uses than just that

But either way that is not so much the challenge as it is getting the file to recognize if it is loaded as an api or not, that is the real question

An example of what Lyqyd mentioned:

if shell then
  -- File is being executed as a script.
else
  -- File is being loaded as an API.
end

so what would be the case if I'd been running shell in multishell?

also what are all these os variables that people can use and is there any documentation for them. like you used ^^ was shell. Can you do such for all included processes?

The idea is that variables, if used directly within conditional checks, count as true if they exist or false if they don't.

So, if there's a table called shell defined (that is to say, the table holding all the functions from the shell API!), the example flags as true. If there's no such variable, it doesn't.

os.loadAPI() works by running your API script in its own custom environment table, where it has access to everything in _G, but doesn't have access to anything in the regular user environment (a separate environment table, which holds all the globals created by regular scripts). Once the script finishes, the function takes every global variable the script defined (eg functions and whatnot, which are all in the environment table), bungs them in a table named after the API itself, and sticks that into _G. This table is where you then access your loaded API's functions from.

Eg, if you make an API called "myAPI", and have it define a function called "myFunc", then the table ends up being called "myAPI" and you access the function via "myAPI.myFunc".

The shell and multishell "APIs" happen to only be available to the user environment (they're not loaded in the way regular APIs are - they're regular scripts which just happen to define some global functions for other scripts to use), so if the script can't see any variable by the name of eg shell, it can assume it's being loaded as an API (because shell is only available in the user environment). multishell isn't always present, but shell is always loaded, so that's the best one to check.

Now aren't you glad you asked? :)/>

It might be simpler to say that this works.

Oh yes! Thank you Bomb! This solves exactly what I needed!!!!!!