Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

plugins/progress: A better progress bar #135

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

grobertson
Copy link

@grobertson grobertson commented Feb 22, 2020

Fixed a bug in the existing progress bar plugin where "phase" was misnamed.

Then I couldn't leave well enough alone so I wrote a much better version.

I left the original version with my fix, and named my rewrite progress2. I wasn't sure about just rm'ing it, but my version is backwards compatible with the existing plugin.

To try it out, first source the progress2.plugin.sh script. Then just ...

for i in {0..100}; do progress2 $i; done

@nntoan nntoan added community-feature Community feature merge request P3 - Normal Priority 3 - Normal labels Feb 24, 2020
@nntoan nntoan changed the title A better progress bar plugins/progress: A better progress bar Jun 11, 2020
Copy link
Author

@grobertson grobertson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ping. -- This has been sitting a while, and was approved a long time ago. Any plans to merge it?

Thanks!

Copy link
Contributor

@akinomyoga akinomyoga left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this new file should be placed in a separate directory plugins/progress2.

################################################################################
#Usage:
# source into your script.
# progress int n(1...100) string<"Phase">
Copy link
Contributor

@akinomyoga akinomyoga Dec 25, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you explain the reasoning for changing the header style? If we should follow this style for some reason, should we also update lib/util.sh, which has a similar header?


source $OSH/plugins/progress/progress2.plugin.sh

for i in {0..101}; do progress $i; done
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo?

Suggested change
for i in {0..101}; do progress $i; done
for i in {0..101}; do progress2 $i; done

Also, why does the above example finally call progress2 101?

Comment on lines +70 to +71
_COMPLETE=$(printf %${_LEFT_COUNT}s | tr " " $_COMPLETE_CHAR)
_REMAIN=$(printf %${_RIGHT_COUNT}s | tr " " $_REMAIN_CHAR)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We would like to reduce the number of forks and execs for efficiency reasons. We require Bash 3.2 for oh-my-bash, so we can use printf -v _COMPLETE ..., and tr can be replaced by _COMPLETE=${_COMPLETE// /$_COMPLETE_CHAR}.

function progress2() {
# Set the initial vars if they haven't been set already.
if ((${#_REMAIN_CHAR} == 0)); then init_progress; fi
_PCT_NOW=$1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
_PCT_NOW=$1
local _PCT_NOW=$1

Please also declare local for the other variables whose values do not need to be preserved among the calls of progress2.

_COMPLETE=$(printf %${_LEFT_COUNT}s | tr " " $_COMPLETE_CHAR)
_REMAIN=$(printf %${_RIGHT_COUNT}s | tr " " $_REMAIN_CHAR)
echo -ne "$_GAUGE_LABEL$_OPEN_GAUGE_CHAR$_COMPLETE$_REMAIN$_CLOSE_GAUGE_CHAR $_OPEN_PCT_CHAR$_PCT_NOW%$_CLOSE_PCT_CHAR\r"
sleep $_STEP_DELAY
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we insert a delay here? The progress bars are used to indicate the progress of an actual task that takes a long time. If we insert a delay here, the processing time will further increase. Or, is progress2 intended to show fake progress bars?

Comment on lines +39 to +47
_STEP_DELAY=0.01
_REMAIN_CHAR="."
_COMPLETE_CHAR="#"
_OPEN_GAUGE_CHAR='['
_CLOSE_GAUGE_CHAR=']'
_GAUGE_LABEL="Progress:"
_OPEN_PCT_CHAR="("
_CLOSE_PCT_CHAR=")"
_PCT_THEN=0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are recently thinking of namespacing variables specific to each plugin or alias. Maybe could you rename them to have the form _OMB_PLUGIN_PROGRESS2_*?

# to customize the display.
function init_progress {
# Make $LINES $COLUMNS available using the builtin magic of shopt!
shopt -s checkwinsize
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shopt -s checkwinsize will not take effect until the first execution of an external command or a subshell command (...). For example, we can insert a line [[ ${COLUMNS-} ]] || (true) # force update COLUMNS after shopt -s checkwinsize.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
community-feature Community feature merge request P3 - Normal Priority 3 - Normal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants