The test currently fails because the test suite doesn't support nested calls, like $(wp option get).

We use the And save STDOUT as {VAR} step as a workaround.

I suppose it wouldn't be impossible to devise a regex that replaces this:

$(wp option get)

with this:

$(/absolute/path/to/bin/wp option get)

and get rid of the workaround.

Or we could just set wp as an alias in the subprocess, leaving bash to do the rest.

See #475

I'm still not convinced there's a bug. In https://travis-ci.org/wp-cli/wp-cli/builds/7552302 the test fails because STDOUT also contains a confirmation message:

Success: Made 1003 replacements.

In this case the current code works, but alternatives I was considering might not.

You mean there's some edge case where the command wouldn't work correctly? Please explain.

The test that fails makes 1000 replacements in the guid column, changing http://example.com to http://newdomain.com. The bug happens when the iterator then tries to get the next chunk using WHERE guid LIKE %http://example.com% LIMIT 1000 OFFSET 1000, but the columns that have been changed no longer match the LIKE. There are 200 matches left to change still, but they are now in the first chunk and the OFFSET 1000 skips them.

The tests for this are slow. Would it be worth making chunk size a parameter to facilitate smaller tests?

The bug happens when the iterator then tries to get the next chunk using WHERE guid LIKE %http://example.com% LIMIT 1000 OFFSET 1000, but the columns that have been changed no longer match the LIKE.

Now I get it. Thanks!

The tests for this are slow. Would it be worth making chunk size a parameter to facilitate smaller tests?

I would prefer not to make it an explicit parameter.

I took a stab at handling this in the iterator instead.

The code looks solid now. Thanks!

Man, those tests really are slow.