It'd be nice to have an API function to display the progress of a loop or iterator, for instance, if you are looping over an array of items and performing some operation. I've attached a sample drush script so you can see what I mean.
If you see value in this, I can work up a patch. I really wish there was a way to get this working when in backend context, but I can't seem to get the \r's to make it through. To get around that, I have the progress indicator simply log a percentage every 10 seconds when in backend context. I'm not familiar enough with where that might be getting stripped out in the backend functions, so if someone knows where that would be, let me know.
Comment | File | Size | Author |
---|---|---|---|
#1 | Screen Shot 2012-08-22 at 11.16.55 AM.png | 6.53 KB | q0rban |
progress.php_.zip | 1.97 KB | q0rban |
Comments
Comment #1
q0rban CreditAttribution: q0rban commentedHere's a screen shot of what it looks like in action.
Comment #2
q0rban CreditAttribution: q0rban commentedSimplified the progress bar function.
Comment #3
moshe weitzman CreditAttribution: moshe weitzman commentedLooks handy to me. Would it be possible to allow the caller to return a line of status text. The canonical example for me is migrate-import which wants to report status like
Processed 3 (3 created, 0 updated, 0 failed, 0 ignored) in 0.1 sec (2467/min)
. I'm not sure that migrate-import would use this feature (it is nice to be able to scroll back and see if your rate is increasing/decreasing) but it is a nice feature i think.Comment #4
q0rban CreditAttribution: q0rban commentedInteresting project here:
http://pear.php.net/manual/en/package.console.console-progressbar.php#ex...
This is much more feature rich, but also a little more complex to set up and run.
Comment #5
moshe weitzman CreditAttribution: moshe weitzman commentedReusing PEAR package makes sense to me.
Comment #6
greg.1.anderson CreditAttribution: greg.1.anderson commentedThis issue was marked
closed (won't fix)
because Drush has moved to Github.If this feature is still desired, you may copy it to our Github project. For best results, create a Pull Request that has been updated for the master branch. Post a link here to the PR, and please also change the status of this issue to
closed (duplicate)
.Please ask support questions on Drupal Answers.
Comment #6.0
greg.1.anderson CreditAttribution: greg.1.anderson commentedFix CR.
Comment #7
pounard@q0rban There is a fundamental problem with your code, you don't let the user explicitly tell that the progress ended: problem behind this is that when you have a very high count items to process, the ratio ends up to 1 quite easily even though it's unfinished and it is error prone. What happens then is that until the progress is unfinished and the ratio keeps rounded to one, you add a new line per print and end up with multiple progress bars being displayed.
Did this code and using it successfully:
Hope it might help someone.
Comment #8
q0rban CreditAttribution: q0rban at Lullabot commentedThanks for sharing, @pounard! I think we should use the PEAR package. Also, we should move this to GitHub if there is still interest. :)
Comment #9
greg.1.anderson CreditAttribution: greg.1.anderson commentedYes, this should move to GitHub if there is any desire to have it reviewed and included. Is that project available via Composer? We don't use Pear for dependencies any more.
Comment #10
pounardJust an update, works fine here, take into account elasped, eta, provide a few new options, adapts the bar depending on the info displayed, and provide an OOP interface, and finally provide a strict ->stop() method to tell the progress bar it ended instead of trying to guess it with ratio (ratio makes it bugguy a soon as your float value is approximated to 1 by the VM).
https://gist.github.com/pounard/3c1679e32eca87ecf7cf