11 replies to this topic

[theoriginalbit]

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 happens
The 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/2fHaX

Additional Info
Upon 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))

[Dlcruz129]

Interesting. This definitely looks like a bug.

[Grim Reaper]

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.

[theoriginalbit]

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.

[Dlcruz129]

Why? What makes strings passed as arguments any different than other strings?

[Grim Reaper]

Here's some code that will fix new line characters.

local tArgs = { ... }
local fixedArgument, numChangesMade = string.gsub (tArgs[1], "%\\n", '\n')

[theoriginalbit]

Cool thank you Grim

[Lyqyd]

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.

[theoriginalbit]

Nah it does actually print Hello\n ... the second would be an interesting bug!!

[Lyqyd]

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.

[immibis]

@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.

[ChunLing]

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?