5 ms·
Show HN: Progressbar - A C library for displaying command-line progress bars
- sigil 11y agoSee also the `pv` program: http://www.ivarch.com/programs/pv.shtml http://www.ivarch.com/programs/pv.shtml
- brobinson 11y agoA screenshot in the readme of what it looks like would go a long way.
- jsprogrammer 11y agoYep, easily a 10x multiplier.
- SloopJon 11y agoThe output of the demo program, FWIW: $ ./demo Smooth |=====================================================| ETA: 0h00m06s Three Second Task with a long label |========================| ETA: 0h00m03s Fast |=======================================================| ETA: 0h00m02s Custom <.....................................................> ETA: 0h00m06s Indeterminate: 0:00:03 Status bar with a really long label: 0:00:01 Custom: 0:00:03
- copperx 11y agoI'm a bit surprised that this didn't exist before.
- Exuma 11y agoCan we get a screenshot?
- AndyKelley 11y agoThe API doesn't let you set the progress, you must know in advance how many steps there are and then call the increment function that exact number of steps. This is not conducive to, for example, a network transfer where you have some total number of bytes, and then you receive a packet of some arbitrary size and you want to set the progress to a percent.
- khanan 11y agoAs mentioned earlier, pv have been around for ages and does this "the right way" (tm). Also, as an exercise, spot the potential buffer overflow in this source in less than 10 seconds for extra credits!
- rodrickbrown 11y agostrcpy(new->format, format);
- ised 11y agoI prefer progress(1) written for BSD UNIX. Dates back to 2002.
- _RPM 11y agohttps://github.com/doches/progressbar/blob/master/lib/progressbar.c#L28:L30 https://github.com/doches/progressbar/blob/master/lib/progre... The correct solution would be a) check the length of format, and if it less than or equal to 4 but greater than 0, then copy the bytes, else, don't... I guess? Why is 4 such an arbitrary chosen number? // new->format is allocated to 4 bytes size_t len = strlen(format); if(len > 0 && len <= 4) { memcpy(new->format, format, len); //i to < 4 new->format[3] = '\0'; } Or it just be better to allocate the new->length to the return value of strlen(format) + 1.
- danieldk 11y agoMaybe I am not awake yet (just rolled out of bed), but if new->format is allocated to 4 bytes, then new->format[4] = '\0'; is out of bounds, no?
- _RPM 11y agoYes it was. Good catch. The size of the buffer is 4, so the last byte would be located at 4-1 = index 3. Because we're 0 based...Wow can't believe I did that. it's 12:30 AM here and I've had a few beers tonight. It's common to allocate your size needed plus 1 for the NULL byte. But this programmer only allocates 4 bytes.. with no thought of the NULL byte at the end.
- _RPM 11y agoConsider checking the return value of malloc (e.g: https://github.com/doches/progressbar/blob/master/lib/progressbar.c#L22 https://github.com/doches/progressbar/blob/master/lib/progre...) You're setting users/yourself up for a disaster if you're assuming it will never fail. The standard [0] states that the size of `char` will be 1 byte. So there is no point in doing the sizeof operator on char. (e.g: https://github.com/doches/progressbar/blob/master/lib/progressbar.c#L28 https://github.com/doches/progressbar/blob/master/lib/progre...) 6.5.3.4 - Paragraph 3 > The sizeof operator... (page 80) [0] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
- thinkpad20 11y agoThere's still a point, in terms of readability and consistency. Certainly there doesn't seem to be a downside aside from a few extra characters.
- _RPM 11y agoRedundant != consistent. But I agree with you, there isn't really a downside. I'm being pedantic here. -pedantic
- spash 11y ago> I'm being pedantic here. Please be. Seemingly random bits of (honestly - actually very useful) information like yours are why I'm reading HN in the first place instead of, say, random Youtube comments. Someone may argue about this being overly pedantic, or about such comment being more suitable for sites like Stack Overflow, or about the whole thing being completely clear from the standards documentation itself... etc. But that's really not the point of it when this isn't the kind of thing you would be even intentionally looking at, or for, in the first place. Every time I open a HN thread, I can be sure that I will find at least a good few nice and memorable comments that seemingly don't add anything revolutionary to the topic at hand, but instead will make you pause, slap your forehead and exclaim "holy moly, that's in essence actually perfectly obvious, yet somehow I never even thought about it from this point of view before!" Which in turn suddenly makes you realize something completely unrelated in your own world, yet affected or plagued by a similar type of issue, that would otherwise end up completely unnoticed if not for your comment. In short, one man's pedantic can still be other man's sudden epiphany.
- natch 11y agoEverybody, please look at this Readme file. It starts with a section called "What is this thing?" That is a fantastic example of something everyone should have in their OSS projects. A simple section at the top of the main doc that states what the thing is. Seems obvious, but I only mention it because it's so rarely done.
- blt 11y agoBeware weaving progress bar code into computationally heavy routines. As soon as you want to start multithreading, it gets tricky. The worst is a ProgressBar singleton in a big C++ GUI program. If I'm going to bother using a library for progress bars, I want it to deal with all those work of combining multiple threads' progress, i.e. it has a queue, knows each thread's estimated share of the total work, and all the threads push progress messages on the queue.
- eps 11y agoNeeds work ;) progressbar * p; p = progressbar_new_with_format(..., ..., "whoops"); ... yields a buffer overflow. And why do you malloc format to begin with if it's always 3 chars in size?