7508 posts
Location
Australia
Posted 11 March 2013 - 04:56 PM
Ok so while making a program I came across this seeming 'bug'…
The simple script
local args = {...}
write("Hello\n")
write(args[1])
args[1] = "Hello\n"
write(args[1])
How to run it
test Hello\n
What happensThe first write command (which is hard coded) is written to the console and a new line is added because of '\n'
The second command (which comes from runtime args) is written to the console and the new line character is written instead of a new line added
The third write command (which is a hard code overwriting the arg) is written to the console and a new line is added
An image example:
http://puu.sh/2fHaXAdditional InfoUpon some further testing I think that the string processing seems to not process escape characters when they are arguments, put this code after "write(args[1]"
write(tostring((args[1]:gmatch([[\n]])) ~= nil))
1619 posts
Posted 11 March 2013 - 05:21 PM
Interesting. This definitely looks like a bug.
504 posts
Location
Seattle, WA
Posted 11 March 2013 - 05:23 PM
You're right: it's not a bug. The way the strings are read is without escape sequences when passed as arguments from the shell.
7508 posts
Location
Australia
Posted 11 March 2013 - 05:27 PM
Ok thats what I thought. thanx Grim. Know of any way to get the escape sequences in there? I tried gsub, but it didn't work.
1619 posts
Posted 11 March 2013 - 05:31 PM
Why? What makes strings passed as arguments any different than other strings?
504 posts
Location
Seattle, WA
Posted 11 March 2013 - 06:37 PM
Here's some code that will fix new line characters.
local tArgs = { ... }
local fixedArgument, numChangesMade = string.gsub (tArgs[1], "%\\n", '\n')
7508 posts
Location
Australia
Posted 11 March 2013 - 06:44 PM
Cool thank you Grim :)/>
8543 posts
Posted 11 March 2013 - 06:46 PM
When the second line is printed, is it output as Hello\n (the escape sequence) or Hello? (the write attempting to draw a newline character)?
Edit: I ask because the first is the behavior I would expect to see out of this example code, and is certainly not a bug, while the second would be interesting and possibly a bug.
7508 posts
Location
Australia
Posted 11 March 2013 - 06:54 PM
Nah it does actually print Hello\n … the second would be an interesting bug!!
8543 posts
Posted 11 March 2013 - 06:57 PM
Yeah, this is not a bug. The string you've input is literally "Hello\n", which if you were to write properly escaped would be "Hello\\n". The backslash itself doesn't have any special meaning once it's in a string.
997 posts
Location
Wellington, New Zealand
Posted 11 March 2013 - 07:18 PM
@Dlcruz:
Arguments aren't handled differently from other strings - that is, you get exactly what you type. Type \n, get \n.
Strings embedded in the source code are handled differently - they have escape sequences - eg type \n and get a newline.
2005 posts
Posted 11 March 2013 - 08:27 PM
Isn't the problem here basically the same as if we tried using a command line parameter that had a space in it? For instance, if the code were instead
local args = {...}
write("Hello there!")
write(args[1])
args[1] = "Hello there!"
write(args[1])
And we ran this program (test) with Hello there! as the command line argument
test Hello there!
In this case it seems obvious that the space is handled differently from how it would appear as an 'actual' space in the middle of a string.
I guess what I'm asking is, why would we need to be able to pass a newline character in from the command line anymore than we would need to pass a space?