[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: confused by the wierd "q" option of "string.format".
- From: Ross Berteig <Ross@...>
- Date: Thu, 07 Jul 2011 13:48:51 -0700
At 01:06 PM 7/7/2011, you wrote:
On 07/07/2011 21.20, tsuui wrote:
Let's see the documented example:
string.format('%q', 'a string with "quotes" and \n
new line')
Using %q will translate every char with special meaning in the
context of string literals into an escape sequence.
....
gives:
a string with "quotes" and
new line
So what Lua returns is perfectly in line with the specs.
There have been cases where I've really disliked this particular
choice. Both \<newline> and \n are indeed ways to embed a
newline in a string literal. However, when using %q for
human-readable log files, the choice it makes breaks up the
natural formatting of one line per record. In those cases, \n is
the better choice. Worse, lots of other control characters are
left intact in the output where they might be lost, missed, or
damaged by down-stream processes.
For my cases, adding %Q to mean do everything %q does but
translate every byte outside the range of [\32-\126] to either a
single-letter escape or to \<digits> (or better, \x<hex>) would
still preserve the property that the string printed is legal Lua
while removing any dependency on preserving control characters
or any damage to log files or other relatively fixed-format uses.
I note that in my Win7 console, Lua 5.1.4 does the following:
C:...>lua -e "print(string.format('%q','abc\a'))"
"abc"
It may or may not have emitted the \007 represented by the \a,
but if so it was visually lost (and it didn't even go 'ding' so
I've got some configuration details to check into also).
Checking with GnuWin32's port of od(1) we learn that the \a was
indeed in the string constant:
C:...>lua -e "print(string.format('%q','abc\a'))" | od -t x1
0000000 22 61 62 63 07 22 0d 0a
0000010
If a human is expected to see the result of the %q, then I
believe that a transform as I've described for %Q would be
superior. I'd propose changing %q to do this, but I have no idea
what unexpected consequences that might have. Adding a new
format code has the advantage that it can't change the behavior
of any working program. As a mnemonic, `Q` is obviously stronger
than `q`, so it even makes sense.
Ross Berteig Ross@CheshireEng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/