1. 10 Feb, 2015 3 commits
  2. 02 Feb, 2015 1 commit
    • mattcollier's avatar
      Update redis-cli.c · 61290d81
      mattcollier authored
      Code was adding '\n'  (line 521) to the end of NIL values exlusively making csv output inconsistent.  Removed '\n'
      61290d81
  3. 09 Dec, 2014 1 commit
  4. 25 Nov, 2014 1 commit
  5. 30 Oct, 2014 1 commit
  6. 29 Oct, 2014 1 commit
  7. 27 Aug, 2014 9 commits
  8. 09 Jul, 2014 2 commits
  9. 26 Jun, 2014 1 commit
  10. 18 Jun, 2014 1 commit
  11. 17 Jun, 2014 1 commit
  12. 06 Jun, 2014 1 commit
  13. 13 Mar, 2014 1 commit
  14. 05 Mar, 2014 1 commit
    • michael-grunder's avatar
      Improved bigkeys with progress, pipelining and summary · 69917929
      michael-grunder authored
      This commit reworks the redis-cli --bigkeys command to provide more
      information about our progress as well as output summary information
      when we're done.
      
       - We now show an approximate percentage completion as we go
       - Hiredis pipelining is used for TYPE and SIZE retreival
       - A summary of keyspace distribution and overall breakout at the end
      69917929
  15. 25 Feb, 2014 7 commits
  16. 22 Jan, 2014 2 commits
  17. 26 Sep, 2013 1 commit
  18. 04 Sep, 2013 1 commit
  19. 12 Jul, 2013 1 commit
  20. 03 Jul, 2013 2 commits
    • antirez's avatar
      redis-cli: introduced --pipe-timeout. · 3e350126
      antirez authored
      When in --pipe mode, after all the data transfer to the server is
      complete, now redis-cli waits at max the specified amount of
      seconds (30 by default, use 0 to wait forever) without receiving any
      reply at all from the server. After this time limit the operation is
      aborted with an error.
      
      That's related to issue #681.
      3e350126
    • antirez's avatar
      redis-cli --pipe: send final ECHO in a safer way. · 24b37992
      antirez authored
      If the protocol read from stdin happened to contain grabage (invalid
      random chars), in the previous implementation it was possible to end
      with something like:
      
      dksfjdksjflskfjl*2\r\n$4\r\nECHO....
      
      That is invalid as the *2 should start into a new line. Now we prefix
      the ECHO with a CRLF that has no effects on the server but prevents this
      issues most of the times.
      
      Of course if the offending wrong sequence is something like:
      
      $3248772349\r\n
      
      No one is going to save us as Redis will wait for data in the context of
      a big argument, so this fix does not cover all the cases.
      
      This partially fixes issue #681.
      24b37992
  21. 11 Apr, 2013 1 commit
    • antirez's avatar
      redis-cli: raise error on bad command line switch. · 42ba5d37
      antirez authored
      Previously redis-cli never tried to raise an error when an unrecognized
      switch was encountered, as everything after the initial options is to be
      transmitted to the server.
      
      However this is too liberal, as there are no commands starting with "-".
      So the new behavior is to produce an error if there is an unrecognized
      switch starting with "-". This should not break past redis-cli usages
      but should prevent broken options to be silently discarded.
      
      As far the first token not starting with "-" is encountered, all the
      rest is considered to be part of the command, so you cna still use
      strings starting with "-" as values, like in:
      
          redis-cli --port 6380 set foo --my-value
      42ba5d37