An easy-to-use C library for displaying text progress bars.

Overview

What is this thing?

progressbar is a C-class (it's a convention, dammit) for displaying attractive progress bars on the command line. It's heavily influenced by the ruby ProgressBar gem, whose api and behaviour it imitates.

Ok, what the hell is a C-class, and how do I use one?

progressbar is implemented in pure C99, but using a vaguely object-oriented convention.

Example usage:

progressbar *progress = progressbar_new("Loading",100);
for(int i=0; i < 100; i++)
{
  // Do some stuff
  progressbar_inc(progress);
}
progressbar_finish(progress);

Example output (from progressbar_demo.c):

demo output

Additional examples can be found in test/progressbar_demo.c

Why did you do this?

One of the things I miss most when I'm writing C instead of Ruby is the how ridiculously easy it is to write user-friendly, informative CLI apps in Ruby. A big part of that, at least for me, is the ProgressBar gem -- and since most of the time when I'm writing C I'm doing so because I need a tool to handle some long-running, processor-intensive task, I'd really like to have a way of seeing at a glance how much time is remaining and how far along we've gotten. Enter progressbar!

Can I use it?

Of course, if you're so inclined. progressbar is licensed under a simplified BSD license, so feel free to take it and run with it. Details can be found in the LICENSE file.

Why doesn't it compile?

If progressbar fails to build because termcap.h isn't found, you're probably missing the ncurses dev libraries.

gcc -c -std=c99 -Iinclude lib/progressbar.c
lib/progressbar.c:13:45: fatal error: termcap.h: No such file or directory
compilation terminated.
Comments
  • Add CMakeLists.txt file

    Add CMakeLists.txt file

    I included this in a larger C++ project where I use CMake for building so I created a CMakeLists.txt which builds the progressbar and statusbar libraries.

    Using it from my project then needs two lines in my CMakeLists.txt: add_subdirectory(progressbar) target_link_libraries(myprogram progressbar)

    opened by abrock 4
  • Fix segfault on shortening readonly label by allocating memory

    Fix segfault on shortening readonly label by allocating memory

    While I was trying demo with smaller terminal columns <64, the second example caused a segmentation fault.

    It's due to the shortening of the label:

      if (maxstrlen - 10 > 10 && strlen(label) > maxstrlen - 10) {
        label[maxstrlen - 10] = 0;
      }
    

    The label from test/progressbar_demo.c is a literal string and read-only. If the demo passes:

    char label[] = "long label...";
    

    This won't cause any trouble, but I don't think it would be convenient to use this library, therefore I submit this patch.

    opened by livibetter 4
  • progressbar_demo.c not in pure c99, should be built with -std=gnu99

    progressbar_demo.c not in pure c99, should be built with -std=gnu99

    as the title, but I think this is not really important, though.

    test/progressbar_demo.c: In function ‘main’: test/progressbar_demo.c:49:9: warning: implicit declaration of function ‘usleep’ [-Wimplicit-function-declaration] usleep(SLEEP_US);
    ^

    opened by joshua5201 4
  • Modularization of the CMake-files; Use CMake to help find curses.

    Modularization of the CMake-files; Use CMake to help find curses.

    Hello, I have a few suggestions for the the library to make it more seamless to use.

    [ ] The headers in the include-folder should be placed in their own folder, such that the include-folder can be appended to the compiler's search path. That way, I can write #include "progressbar/progressbar.h" to include the library (Note that boost does it that way, too: https://github.com/boostorg/smart_ptr ) [ ] CMake can help find libraries; I used this capability to find curses cleanly. [ ] So far, one monolithic CMakeLists.txt was used to build the library itself and the demo program. I made three of them, with one responsible for building the library, the other one for building the demo and the third one including the others. That way, I can use the CMakeLists.txt in lib only for my own projects such that I don't have to build the demo program, too.

    opened by Mitmischer 2
  • Why stderr instead of stdout?

    Why stderr instead of stdout?

    Thanks you guys for your progressbar, I have used it for a school's project where I have to implement a genetic algorithm for solving QAP (Quadratic Assigment Problem), but I have found in the code that you use "stderr" instead of "stdout," why is it?

    The progressbar works (I have not tried userbar) because by default stderr = stdout. I mean, if I run my application and redirect the error output to some log file (as many Lignux (GNU/Linux) applications do - usually /var/log/ directory), the progressbar will not be displayed in the terminal. I think that it will be better to change "stderr" by "stdout."

    Thanks.

    opened by germelcar 2
  • Fixed segfault when terminal small enough to cause label cutoff and refactored drawing code

    Fixed segfault when terminal small enough to cause label cutoff and refactored drawing code

    There is currently a bug in progressbar where it will crash if resized too small when using a label that is a string literal (and thus modifiable memory). Really though, even though this bug is caused by using a string literal for the label, it shows a problem with how the progressbar views the label string. It either needs to take ownership of it, meaning that is responsible for memory management of it once the user has provided it (which requires the user to pass a malloc'd string and not a literal...), or it needs to leave the memory management of the label up to the caller.

    The second approach seems more reasonable so that we can avoid unnecessary copying of strings or putting a burden on the user, but this means that the amount of the string that should be rendered must be either computed or stored in the bar. In other words, we can't str[idx] = 0 a string we don't own.

    To this end, I started reworking how the progressbar handles rendering of the label, and I might have gotten a bit carried away and ended up refactoring most of the drawing code.

    Technical changes:

    • progressbar no longer modifies the given label at all. Also, it is now explicitly documented that the user is responsible for ensuring that the label continues to exist throughout the existence of the progressbar.
    • progressbar no longer stores the terminal type. That's an implementation detail of rendering, and struct progressbar is responsible for modeling a progressbar.
    • step and steps are no longer stored on the progressbar. Again, they're artifacts of rendering, and they do not belong in the progressbar object. They are now calculated during rendering.
    • Some #define macros were converted to be enum-style constants. This allows for better typesafety and a higher likelihood that the symbols will have names in a debugger.
    • The format of the ETA string along with some magic constants (amount of whitespace, bar border width, etc) have been converted to constants.
    • progressbar_draw is no longer exposed in the header or exported in the source. This is a backward compatibility breaking change. Anyone who used the progressbar_draw method will have to alter their code to be compatible with new versions of progressbar if this PR is accepted. However, the method does not make much sense to call directly anyway, and it's documented as internal, so I'm hoping this is acceptable.
    • progressbar_draw no longer takes in an ETA but rather calculates it itself. This allowed for removing a lot of replicated code at various calling sites to calculate elapsed time, items remaining, etc.
    • The actual bar component of the progressbar no longer requires a buffer to render. Instead, it is rendered straight to stderr.
    • Width calculations have been broken out to be a bit clearer and more contained.

    Improvements in functionality:

    • The bar no longer segfaults when sized below a certain width.
    • The bar now resizes instead of sticking to the size of the terminal when the bar first rendered. Currently it only resizes when the bar is redrawn, but it should be trivial to add a listener for the terminal resizing and redraw appropriately if someone were so inclined.
    • The bar is now the full width of the terminal instead of having two trailing blank spaces (I believe there was a bug with the width calculations where the ETA was given more space than it needed).
    opened by nibroc 2
  • Fixed accessing progressbar->steps before initialization

    Fixed accessing progressbar->steps before initialization

    When calling progressbar_update_label in progressbar_new_with_format, bar->steps has not been initialized, meaning undefined behavior is invoked. Fixing this just requires setting steps before it's accessed in progressbar_new_update_label.

    opened by nibroc 2
  • static lib (.a) and long ints for handling large data counts

    static lib (.a) and long ints for handling large data counts

    This patch adds a facility to compile a static lib (which is nice in some contexts) and also use 64-bit unsigned integers for tracking progress, which is important when we have many billions of items to process.

    opened by ekg 2
  • check if malloc failed and return NULL

    check if malloc failed and return NULL

    Though it is unlikely that malloc will fail, it is good practice to check for failure and return NULL. If allocation of new->format fails, we have to free new in order to avoid a memory leak.

    opened by michael-hartmann 1
  • Refactored Makefile to support debug builds, doc generation and be a bit DRYer

    Refactored Makefile to support debug builds, doc generation and be a bit DRYer

    These changes do the following:

    • Get rid of some minor repetition
    • Allow debug building of the demo (make debug)
    • Allow generation of documentation via make (make doc)
    • Get rid of manual commands where possible (i.e. use make implicits instead of rules for each object)
    • Allow easier overriding of CC so people can build with clang or whatever without having to do something like make -e CC=clang and instead do the more usual CC=clang make
    • Append to CFLAGS instead of overwrite it so that people can more easily overwrite CFLAGS without having to copy/paste default flags into their overriding (CFLAGS="whatever" make vs `CFLAGS="CFLAGS from makefile + whatever" make")

    The Makefile could still use a bit of cleaning up with regards to repeating file names (i.e. deriving source files names from header files), and it would be nice if out of source builds were easier, but hopefully this will be a useful improvement.

    opened by nibroc 1
  • Fix integer-signedness problems

    Fix integer-signedness problems

    Enabling -Wall -Wextra -pedantic yields a few warnings about comparing signed and unsigned integers. This PR fixes most of them. (The exception is the one involving newsteps, since it is explicitly being checked for a negative value.)

    opened by jack126guy 1
  • Undefined symbols for architecture x86_64 Error

    Undefined symbols for architecture x86_64 Error

    I'm getting the below error when compiling in my project when statically linking with the progressbar lib:

    Undefined symbols for architecture x86_64:
      "_tgetent", referenced from:
          _get_screen_width in libprogressbar.a(progressbar.o)
      "_tgetnum", referenced from:
          _get_screen_width in libprogressbar.a(progressbar.o)
    ld: symbol(s) not found for architecture x86_64
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    make: *** [bin] Error 1
    

    I'm on a 2019 macbook running Catalina 10.15.6. I Tried to use the -m64 arg when building my code with the progressbar lib but havent yet tried this flag when building the progressbar project directly.

    opened by joegasewicz 2
  • Working with XCode's debug console

    Working with XCode's debug console

    Is there a smart way to integrate this ( fanstatic ) library to work with the XCode debug window?

    I can get xCode to open Terminal and the Progressbar works as expected. But if you use the Native xCode debug window it prints a non-beautiful progressbar..

    opened by rustymagnet3000 0
  • Pullrequest

    Pullrequest

    Modifications:

    1. Updated makefile: i. also builds shared and static libraries for statusbar in addition to progressbar; ii. make install option
    2. Updated readme with instructions for installing the libraries and using them.

    Updated makefile: 1. build libraries for statusbar as well; 2. make install

    opened by rsnemmen 0
Owner
Trevor Fountain
Trevor Fountain
Haxe bindings for raylib, a simple and easy-to-use library to learn videogame programming

Haxe bindings for raylib, a simple and easy-to-use library to learn videogame programming, Currently works only for windows but feel free the expand t

FSasquatch 36 Dec 16, 2022
RapidObj is an easy-to-use, single-header C++17 library that loads and parses Wavefront .obj files.

RapidObj About Integration Prerequisites Manual Integration CMake Integration API RapidObj Result Next Steps OS Support Third Party Tools and Resource

Slobodan Pavlic 108 Jan 2, 2023
Library for writing text-based user interfaces

IMPORTANT This library is no longer maintained. It's pretty small if you have a big project that relies on it, just maintain it yourself. Or look for

null 1.9k Dec 22, 2022
The libxo library allows an application to generate text, XML, JSON, and HTML output using a common set of function calls. The application decides at run time which output style should be produced.

libxo libxo - A Library for Generating Text, XML, JSON, and HTML Output The libxo library allows an application to generate text, XML, JSON, and HTML

Juniper Networks 253 Dec 10, 2022
Rich text library supporting customizable Markdown formatting

Rich text library supporting customizable Markdown formatting

Brace Yourself Games 95 Dec 30, 2022
A library to automatically generate a text based interface for programs and libraries.

Introduction Auto Menu is an open-source library to automatically generate a text based interface for your programs and libraries. Installation Clone

Soumya Ranjan Patnaik 7 Oct 31, 2021
Mustache text templates for modern C++

About Mustache implementation for modern C++ (requires C++11) Header only Zero dependencies Templated string type for compatibility with any STL-like

Kevin Wojniak 307 Dec 11, 2022
Read Non-Rectangular Text Data

meltr The goal of ‘meltr’ is to provide a fast and friendly way to read non-rectangular data (like ragged forms of ‘csv’, ‘tsv’, and ‘fwf’). Standard

R infrastructure 29 Dec 26, 2022
A c++ file just to show how can we change color of Background and Text in C++...

A c++ file just to show how can we change color of Background and Text in C++...

null 1 Nov 2, 2021
A linux library to get the file path of the currently running shared library. Emulates use of Win32 GetModuleHandleEx/GetModuleFilename.

whereami A linux library to get the file path of the currently running shared library. Emulates use of Win32 GetModuleHandleEx/GetModuleFilename. usag

Blackle Morisanchetto 3 Sep 24, 2022
runsc loads 32/64 bit shellcode (depending on how runsc is compiled) in a way that makes it easy to load in a debugger. This code is based on the code from https://github.com/Kdr0x/Kd_Shellcode_Loader by Gary "kd" Contreras.

runsc This code is based on the code from https://github.com/Kdr0x/Kd_Shellcode_Loader by Gary "kd" Contreras and contains additional functionality. T

null 24 Nov 9, 2022
CppDyn is a library which aims to simplify use of polymorphism in C++20

Cpp Dyn Cpp-Dyn tries to improve C++ runtime polymorphism. Indeed, C++ runtime polymorphism, originally, uses inheritance and virtual methods. Sean Pa

Antoine MORRIER 14 Jun 7, 2022
A tool for use with clang to analyze #includes in C and C++ source files

Include What You Use For more in-depth documentation, see docs. Instructions for Users "Include what you use" means this: for every symbol (type, func

null 3.2k Jan 4, 2023
Utilities and common code for use with raylib

Utilities and shared components for use with raylib

Jeffery Myers 86 Dec 1, 2022
A ring buffer designed to work with embedded devices, does not use heap allocations.

Embedded Ring Buffer This is a header only ring buffer that is designed to work on embedded devices, it is able to handle non-blocking ISR spooling

Richard Bamford 49 Dec 2, 2022
Find patterns of vulnerabilities on Windows in order to find 0-day and write exploits of 1-days. We use Microsoft security updates in order to find the patterns.

Back 2 the Future Find patterns of vulnerabilities on Windows in order to find 0-day and write exploits of 1-days. We use Microsoft security updates i

SafeBreach Labs 118 Dec 30, 2022
A Header-Only Engine that tries to use SFML in a deeper level

⚙️ SFML-Low-Level-Engine ⚙️ A header-only library that tries to use SFML at a deeper level ?? Instalation Download the source code and put the GLD fol

!Gustavo! 4 Aug 27, 2021
use ptrace hook Hotspot JavaVM, instrument java bytecode

taycan 通过native层修改java层(JVM),使用JVMTI及JNI API可以修改java任意类、执行任意代码,完成hook、插入内存马、反射等功能。 适用环境 LINUX KERNEL version > 3.2 GLIBC > 2.15 openJDK/OracleJDK 1.8

null 26 Jul 12, 2022
Utilities for use in a DPP based discord bot

DPPUtils NOTE: This repo is in development, use these utilities at your own risk Numerous utilities for use in your DPP bot. List of Utilities Youtube

Daniel Wykerd 6 Nov 5, 2022