[Bashdb-devel] reading progress...

[R. B. <ro...@pa...>]

Masatake YAMATO writes:
 > I've changed the reading progress notation to percentage style.
 > If we can show a progress bar, it may be the best.
 > But, I don't know how to erase written string on a terminal in a shell script.

I have some reservations about the patch below. I'm not against giving
percentage versus lines read in per se. But here it comes with a some
cost and perhaps reliability. The patch assumes that "wc" and "cat"
are available commands and are in the path. (With extra work configure
could check this and hard-code in the paths).  I don't belive the rest
of the debugger makes use of either "cat" or "wc".  Perhaps the build
system does, but I suppose that's okay since it is for developers. I
don't know, I may be overly fussy here. 

And there's something I find weird about running a "cat | wc -l" just
to get the total number of lines in a file. Right now, For the simple
cases where the script is under a 1,000 lines, no extra work is done
no, wc'ing no cat'ing no line printing. In those cases where one
needs to print out status because the file is large, running 'cat | wc
-l' slows things down more.

But this is just my view. What do others think? If folks feel the
benefits outweigh whatever disadvantages, by all means add it.

If the patch is added, some small comments. 

 > +    local line_count=`cat $fullname|wc -l`

local -i might be better. I would be neat if there were a way to give
$fullname to wc rather than piple the whole file to wc.  Also, I think
it clear when the definition is put as close as possible to would be 
after the test on $fullname. 

 > +	  (( i==1000 )) && _Dbg_msg_nocr "Reading $filename: \n"
 > +	  _Dbg_msg_nocr "\t$(( 100 * ${i} / ${line_count} ))%..."

One should check that $line_count is not 0 before dividing. If it is
zero (perhaps something went wrong) then probably one should fall back
to giving line number counts.