Open GoogleCodeExporter opened 9 years ago
Also, just noticed that values echoed to STDOUT do not properly handle EOL.
redis-cli does not escape even basic things like newlines upon
storage/retrieval and really shouldn't be used to retrieve any sort of
untrusted data. I can't really access redis from short-lived processes unless I
want to (carefully) write them in C because most scripting languages take a
while to start up (sometimesy 10x the startup latency compared a bash script
once the redis lib is included.)
here's an example:
$ redis-cli lpush samplelist "value with space"
(integer) 4
for i in `redis-cli lrange "samplelist" 0 100`; do echo "value: ($i)"; done
value: (value)
value: (with)
value: (space)
value: (value3)
value: (value2)
value: (value1)
Ideally, each value would have an EOL (\n) between, and \n's would be escaped
on input. This is really a separate but closely related bug, so let me know if
you want me to open a second bug report for this.
Original comment by jamiesonbecker@gmail.com
on 24 Mar 2011 at 2:17
Output of redis-cli being separated by spaces is not a redis-cli issue, but
rather a shell one. If you try running the loop against "echo value with
spaces", you'll see the exact same thing. Bash (not sure about other shells)
use whitespace as a field separator by default, so will always see a single
line with strings separated by spaces as multiple elements. You can use the IFS
variable to override the character bash splits on.
By default, redis-cli delimits every element in a multi-bulk with an EOL, but
this can be customized by passing the -d option to redis-cli (also see --help,
v2.2). For instance, delimiting by the NUL character and piping the output to
xargs -0 can be very useful.
Printing the special values (nil) and (empty list or set) to stderr sounds like
a good plan. I don't think, however, that changing the exit status is a good
idea, because that is currently used to signal not being able to connect. When
the special values are printed to stderr, you can simply test for empty output
on stdout to know if there was a reply or not. Leaving this issue open for
printing specials to stderr.
Original comment by pcnoordh...@gmail.com
on 24 Mar 2011 at 8:36
Original issue reported on code.google.com by
jamiesonbecker@gmail.com
on 24 Mar 2011 at 2:00