I was reading the forums the other day and came across this little bit of code in a post:
local file = assert(io.open("output.lua", "w"))
file:write("Hello world")
I wanted to know more about writing a file like this in Lua. Can I name "output.lua" as "output.txt" without any problems? Also, I'm assuming that the "w" flag is for writing, is there a "r" for read, and "a" for append, etc.
Also, where is the default directory for "output.lua"? Can I specify a different directory?
Is there any way at all to write some sort of custom log-file in the game?
No, but honestly this is another basic feature they should have... make it with a delayed write and append only... but.... they really should put it in.
You could join a custom chat channel and output your log information to that channel. By enabling chat logging, you get a file with all your chat activity (and therefore also your log-channel). That log is written during gameplay.
I've thought about doing that. The one problem I see is when people are already logging chat, my log and their log get mixed together. Not that I know anybody who logs chat all day long, but it's still possible.
I agree that it would be nice to be able to open a custom log file.
I don't. The thought of authors being able to write files to my HDD sends shivers down my spine.
Interesting thought. Have you given consideration to the fact that we're already doing that with saved variables, and the code itself that you're downloading and installing? Or are you checking everything you download in some sort of text editor first?
Indeed, and writing an appending log file would of course be sandboxed to just be in one directory with the name of the addon being the base file name etc... so it would add almost no risks not already present.
Interesting thought. Have you given consideration to the fact that we're already doing that with saved variables, and the code itself that you're downloading and installing? Or are you checking everything you download in some sort of text editor first?
See, the thing is, the WoW client does that, not the addon author. The saved variables file is read into RAM, the addon(s) modify those variables while in RAM, and WoW dumps the data back to the file when the player logs out.
Interesting thought. Have you given consideration to the fact that we're already doing that with saved variables, and the code itself that you're downloading and installing? Or are you checking everything you download in some sort of text editor first?
Indeed, and writing an appending log file would of course be sandboxed to just be in one directory with the name of the addon being the base file name etc... so it would add almost no risks not already present.
The worst thing that a malicious addon author can do today is to keep adding huge strings of gibberish to a table, and then wait for the WoW client to write that table to disk as part of SavedVariables. No matter how big the table gets, it's tiny compared to the available disk space. At most, the table will use up the available memory and the player will have to restart the game.
If a malicious addon author can write directly to the drive, then they can just keep on appending data until the drive is filled, or until the file is large enough that the OS has problems with it. How many players would know what to look for to solve that problem, or even just to recover from it? We're not talking developers here, we're talking Grandpa and Grandson who enjoy questing together on the weekend being asked to find unusually large files in a subfolder that they didn't even know existed.
Even if it's sandboxed, you would have to have previously taken steps like isolating WoW to its own partition or other -- let's be honest -- unreasonable steps in order to safeguard against that. There are any number of ways to sort of prevent that, like size limitations monitored by the client, but (1) they probably would work most of the time but probably wouldn't be foolproof, and (2) they would likely eventually interefere with legitimate addons, because arbitrary restrictions eventually always do.
"Probably" does not make me feel warm and fuzzy about the security and stability of my computer. I think I'm just as happy knowing that addons can't see the drives. But that's just my opinion.
See, the thing is, the WoW client does that, not the addon author. The saved variables file is read into RAM, the addon(s) modify those variables while in RAM, and WoW dumps the data back to the file when the player logs out.
See the thing is , the OS does that, not the WoW client. The WoW client asked the OS to read the file into ram and the the WoW client asks the OS to dump the file to disk....
so.. umm. not really a logical difference we already have abstractiion layers.... and this point is not for any file writing anywhere on the system, it can be sandboxed .
The worst thing that a malicious addon author can do today is to keep adding huge strings of gibberish to a table, and then wait for the WoW client to write that table to disk as part of SavedVariables. No matter how big the table gets, it's tiny compared to the available disk space. At most, the table will use up the available memory and the player will have to restart the game.
If a malicious addon author can write directly to the drive, then they can just keep on appending data until the drive is filled, or until the file is large enough that the OS has problems with it. How many players would know what to look for to solve that problem, or even just to recover from it? We're not talking developers here, we're talking Grandpa and Grandson who enjoy questing together on the weekend being asked to find unusually large files in a subfolder that they didn't even know existed.
Even if it's sandboxed, you would have to have previously taken steps like isolating WoW to its own partition or other -- let's be honest -- unreasonable steps in order to safeguard against that. There are any number of ways to sort of prevent that, like size limitations monitored by the client, but (1) they probably would work most of the time but probably wouldn't be foolproof, and (2) they would likely eventually interefere with legitimate addons, because arbitrary restrictions eventually always do.
"Probably" does not make me feel warm and fuzzy about the security and stability of my computer. I think I'm just as happy knowing that addons can't see the drives. But that's just my opinion.
What about already being able to turn on the combat log? Solution here is to have a log rotation system built in the limits the length a file can be....
There's another important considering regarding a logfile. By definition a log file is write-only! The WoW client doesn't ever read it in for any reason, so there's no execution without user interaction.
Also, how does allowing a write-only file help people bot? IMO, it would only help if the same file could be read back into the client.
local file = assert(io.open("output.lua", "w")) file:write("Hello world")I wanted to know more about writing a file like this in Lua. Can I name "output.lua" as "output.txt" without any problems? Also, I'm assuming that the "w" flag is for writing, is there a "r" for read, and "a" for append, etc.Also, where is the default directory for "output.lua"? Can I specify a different directory?
Thanks in advance for the help.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYou can't use explicit file io from wow (just in case that's where you were heading with this).
-
View User Profile
-
View Posts
-
Send Message
Forum Moderator-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNo, but honestly this is another basic feature they should have... make it with a delayed write and append only... but.... they really should put it in.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorI agree that it would be nice to be able to open a custom log file.
Interesting thought. Have you given consideration to the fact that we're already doing that with saved variables, and the code itself that you're downloading and installing? Or are you checking everything you download in some sort of text editor first?
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThe worst thing that a malicious addon author can do today is to keep adding huge strings of gibberish to a table, and then wait for the WoW client to write that table to disk as part of SavedVariables. No matter how big the table gets, it's tiny compared to the available disk space. At most, the table will use up the available memory and the player will have to restart the game.
If a malicious addon author can write directly to the drive, then they can just keep on appending data until the drive is filled, or until the file is large enough that the OS has problems with it. How many players would know what to look for to solve that problem, or even just to recover from it? We're not talking developers here, we're talking Grandpa and Grandson who enjoy questing together on the weekend being asked to find unusually large files in a subfolder that they didn't even know existed.
Even if it's sandboxed, you would have to have previously taken steps like isolating WoW to its own partition or other -- let's be honest -- unreasonable steps in order to safeguard against that. There are any number of ways to sort of prevent that, like size limitations monitored by the client, but (1) they probably would work most of the time but probably wouldn't be foolproof, and (2) they would likely eventually interefere with legitimate addons, because arbitrary restrictions eventually always do.
"Probably" does not make me feel warm and fuzzy about the security and stability of my computer. I think I'm just as happy knowing that addons can't see the drives. But that's just my opinion.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumSee the thing is , the OS does that, not the WoW client. The WoW client asked the OS to read the file into ram and the the WoW client asks the OS to dump the file to disk....
so.. umm. not really a logical difference we already have abstractiion layers.... and this point is not for any file writing anywhere on the system, it can be sandboxed .
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWhat about already being able to turn on the combat log? Solution here is to have a log rotation system built in the limits the length a file can be....
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumsame solution as they use for the existing log writing, a buffer and delay
Also, how does allowing a write-only file help people bot? IMO, it would only help if the same file could be read back into the client.