[Question] Storing Variables

I'm wondering how you can store a variable (as in a password), so it is the same after the program restarts. For example, if you made a program asking the user to set a password, how would it still know that password after a restart. I was thinking you could save the variable to a file, so that way other programs like locks can access that file to determine the correct, user set, password. I saw an old example of this using the IO api, but most of that api has been removed and is no longer working. If you could show a code example and comment it/ explain it well, that would be great. Thanks!

EDIT: In short, I guess you could call it a config file. How do I make a config file?

What do you mean with restart? Shutting down the computer or just pressing ESC when the terminal is opened and the computer is running?

uhhhh you must be using the Tekkit version if your saying the IO api is gone in respects to the file read/write…

in any case yes writing to a file is the best way to remember it (for now) and this can be achieved with the fs api like so

local handle = fs.open( somePath, "w" ) -- "w" tells it write mode, "r" is read and "a" is append (to the end of file)
handle.write(someVar) -- if its a table you need to serialise it first
handle.close()

also I suggest if its a password storing it as a hashed string so that it is not stored in plaintext for just anyone to read.

Mvf314, on 30 January 2013 - 03:48 AM said:

What do you mean with restart? Shutting down the computer or just pressing ESC when the terminal is opened and the computer is running?

Like I said, after the program restarts. Variables revert to default when a computer is restarted, the program was restarted, or the server was restarted.

TheOriginalBIT, on 30 January 2013 - 03:49 AM said:

uhhhh you must be using the Tekkit version if your saying the IO api is gone in respects to the file read/write…

in any case yes writing to a file is the best way to remember it (for now) and this can be achieved with the fs api like so

local handle = fs.open( somePath, "w" ) -- "w" tells it write mode, "r" is read and "a" is append (to the end of file)
handle.write(someVar) -- if its a table you need to serialise it first
handle.close()

also I suggest if its a password storing it as a hashed string so that it is not stored in plaintext for just anyone to read.

I despise tekkit, I was reading it off the wiki.

"file:seek(…) - Doesn't exist."
"io.lines(…) - Doesn't exist either."
"file:read(…) - Doesn't seem to exist in 1.43."
"file:read(number) - Doesn't exist as of 1.46."

May I ask where and how you learned lua and how to use it in computercraft? I've heard of tables, but never used them and don't know what they're used for. My friend and are are trying to learn together.

Could you take the time to tell me what your variable "handle" does? And also how I'd go about reading the variable from a running program out of that file. Honestly, I haven't the slightest clue about how to hash a password in lua. At all. All I know it password are stored in hashes on computers in formats like SHA1.

What I was planning to do it create a folder for the OS and all it's files/programs in the root directory of the computer, like the ROM for CraftOS. In there I would make a folder with the OS name which contains files like the password. It's probably a bad way to do it, and even though there is a startup password and termination lock, I'm sure there is a way to get to the password file none the less. I'm assuming computers still take boot priority to disks, so you could use a disk to get into the computer filesystem anyways.

Have a look at a previous post of mine:
Link

Could you maybe make an example of a program prompting you to enter a password, storing the variable in a file, and then another prompting you for a password and comparing your input to the password stored in the file? I know its a bit much…but I think it should help me understand more if I can see an example or it in action.

NeverCast, on 30 January 2013 - 09:42 AM said:

Have a look at a previous post of mine:
Link

Thanks, I'll be sure to check it out later when I get the chance.

NeverCast, on 30 January 2013 - 09:42 AM said:

Have a look at a previous post of mine:
Link

As much as that is a perfect guide on tables, Im pretty sure the contents of tables also reset as a program gets restarted. Using the way TheOriginalBIT posted is pretty much the only easy way of doing it I think.

On my phone so I can't test…..and there will b typos…..

Spoiler

while true do--loop
if fs.exists("file name")==false then--if the password file doesn't exist
print("welcome ur new. type pass")
pass=read()--have user input password
file=fs.open("file name", "w")--open file
file.writeLine(pass)--store inputed pass to file 
file.close()--close file
end
print("hi type pass")
Input=read("*")--have user type pass...all that shows is *
file=fs.open("file name","r")--open the stored file
pass=file.readLine()--set pass to the stored password
file.close()--close file 
if Input==pass then--if what the user typed is the same as the pass in the file
--do stuff
break--breaks loop
end
end

Hopefully no errors….srry no indents

Novicode, on 30 January 2013 - 09:34 AM said:

May I ask where and how you learned lua and how to use it in computercraft? I've heard of tables, but never used them and don't know what they're used for. My friend and are are trying to learn together.

W00dyR, on 30 January 2013 - 09:51 AM said:

NeverCast, on 30 January 2013 - 09:42 AM said:

Have a look at a previous post of mine:
Link

As much as that is a perfect guide on tables, Im pretty sure the contents of tables also reset as a program gets restarted. Using the way TheOriginalBIT posted is pretty much the only easy way of doing it I think.

He just answered Novicode's question.

Orwell, on 30 January 2013 - 10:06 AM said:

Novicode, on 30 January 2013 - 09:34 AM said:

May I ask where and how you learned lua and how to use it in computercraft? I've heard of tables, but never used them and don't know what they're used for. My friend and are are trying to learn together.

W00dyR, on 30 January 2013 - 09:51 AM said:

NeverCast, on 30 January 2013 - 09:42 AM said:

Have a look at a previous post of mine:
Link

As much as that is a perfect guide on tables, Im pretty sure the contents of tables also reset as a program gets restarted. Using the way TheOriginalBIT posted is pretty much the only easy way of doing it I think.

He just answered Novicode's question.

:)/> ^

Novicode, on 30 January 2013 - 09:34 AM said:

May I ask where and how you learned lua and how to use it in computercraft? I've heard of tables, but never used them and don't know what they're used for. My friend and are are trying to learn together.

Basic concepts from uni. Everything to do with Lua: http://www.lua.org/pil … and related to CC, the wiki, reading other peoples code (and changing it to see what happens) and playing around with it myself.

Novicode, on 30 January 2013 - 09:34 AM said:

Could you take the time to tell me what your variable "handle" does?

The variable 'handle' stores a table of all the functions that can be performed on the given file, take a look here http://computercraft.info/wiki/Fs.open to see what functions you can perform. Basically though its a file, and everything you can do to it, in the computing world these are called File Handles and as such I called it handle.

Novicode, on 30 January 2013 - 09:34 AM said:

And also how I'd go about reading the variable from a running program out of that file.

you just open it with "r" instead of "w" and use readLine() to get the line.

Novicode, on 30 January 2013 - 09:34 AM said:

Honestly, I haven't the slightest clue about how to hash a password in lua. At all. All I know it password are stored in hashes on computers in formats like SHA1.

Lookup GravityScore's Single Function SHA256, its the one that I use all the time now. The simplified explanation of hashing is that no matter what string you enter, whether its 3 characters long or 50 characters long the hash will be a unique (to that string) 64 digit (SHA256 only, others are different sizes) alphanumerical string. And this hash cannot just be simply reversed by anyone or anything (some can though as they have 'dictionaries' for them). To add extra security to your hash it is quite common to add whats called a 'salt', this is just a random string of characters that is known to your program, that can be added anywhere into the hashed string to change its output, this way even if someone can reverse the hash they still don't have the original string, they also have salts in there. NOTE: You must have the program remember the salt… Then when it comes time to see if the password entered was correct, you would get the input, apply the salt, and then hash it. if the two hash codes match then they have entered the correct password (remember, the same strings produce the same hash, if its a different string the hash is also very different)


If you want to see this process in action and how its done, click the link in my signature and check out the "Advanced Door Lock" program.

TheOriginalBIT, on 30 January 2013 - 11:27 AM said:

The simplified explanation of hashing is that no matter what string you enter, whether its 3 characters long or 50 characters long the hash will be a unique (to that string) 64 digit (SHA256 only, others are different sizes) alphanumerical string.

I know you're simplifying, but hashes don't have to be unique. Think about it, how can you map an infinite number of string combinations to a finite set of hashes? The trick is to have these so called collisions spread out. So that the chance of having collisions between strings of a realistic length is minimal. The fact that these collisions exist is the basis of the theory behind rainbow tables.

Orwell, on 30 January 2013 - 11:57 AM said:

I know you're simplifying, but hashes don't have to be unique. Think about it, how can you map an infinite number of string combinations to a finite set of hashes? The trick is to have these so called collisions spread out. So that the chance of having collisions between strings of a realistic length is minimal. The fact that these collisions exist is the basis of the theory behind rainbow tables.

Yeh ik, but as you said, I was trying to simplify it as much as possible.

TheOriginalBIT, on 30 January 2013 - 12:04 PM said:

Orwell, on 30 January 2013 - 11:57 AM said:

I know you're simplifying, but hashes don't have to be unique. Think about it, how can you map an infinite number of string combinations to a finite set of hashes? The trick is to have these so called collisions spread out. So that the chance of having collisions between strings of a realistic length is minimal. The fact that these collisions exist is the basis of the theory behind rainbow tables.

Yeh ik, but as you said, I was trying to simplify it as much as possible.

Indeed, but saying that they have to be unique is wrong. And simplifying is no reason to give incorrect information. :P/> I'm not saying that you didn't know, simplifying can be hard.

Orwell, on 30 January 2013 - 12:08 PM said:

Indeed, but saying that they have to be unique is wrong. And simplifying is no reason to give incorrect information. :P/> I'm not saying that you didn't know, simplifying can be hard.

It can be very hard to simplify so that info is correct, but easy enough to understand. I could have actually sworn I said "seemingly unique" but clearly I didn't.

the answer is simple: computercraft needs to implement NVRAM

That is just a specially obnoxious version of "have someone else code it for me with no effort on my part". Which is only a "simple" answer from a single point of view.

ChunLing, on 30 January 2013 - 03:44 PM said:

That is just a specially obnoxious version of "have someone else code it for me with no effort on my part". Which is only a "simple" answer from a single point of view.

sorry. if i knew java well enough to understand JAD's approximation of dan200's source code well enough, i would write it myself, but i dont