APT's progress bar does have issues though. When you shrink the terminal when the progress bar is visible, you're going to have gibberish in the terminal. That's because the terminal commands to move the cursor by lines work on visual lines, not semantic lines, so they aren't invariant under the operation of resizing the terminal window. That's a really rough area of Linux terminals: when you resize a window, the terminal is going to rewrap the lines according to semantic lines (based on line feed characters), so it's clear that all major terminals understand this distinction, but the terminal API doesn't give applications access to moving by semantic lines, so we're left with bugs like these.<p>I think PowerShell has the concept of progress reporting specially recognized? That sounds like a good idea. It could be used to render a GUI progress bar and leave the pipeline alone, for the objects. That's just my vague idea, since I didn't spend much time with PowerShell.
For those who wonder how these "\033[1A..." notations are specified, look up "ANSI escape code" on the net, e.g. <a href="https://en.wikipedia.org/wiki/ANSI_escape_code" rel="nofollow">https://en.wikipedia.org/wiki/ANSI_escape_code</a>
It's good to know the underlying low-level terminal commands that make this work like this article explains. But I guess most people will use a terminal abstraction library that has a higher level API to move the cursor, clean the screen etc.<p>Terminals are complex beasts and they can do powerful things. If you're interested in this, I can recommend reading the source code for Tmux, JLine3 and some other libraries shell formatting or TUI libraries.
This kind of fancy terminal manipulation is usually an accessibility nightmare.<p>Real GUI frameworks usually provide semantic information to the OS, which allows screen readers to determine that a given control is a progress bar that is 50% filled, and then render that information by playing an appropriately-pitched tone. In a TUI, all they get is a line of fancy symbols changing quickly, with no context as to what those symbols mean. Same for i.e. ncurses based menus. When programs use colors to signify which menu option is selected, screen readers usually get lost.<p>Screen readers specifically designed for text-based systems (such as DOS) usually had ways to work around this issue, but modern, GUI-focused ones don't really offer those options any more.
Nice. I also looked into this a while ago and came up with a very simplistic (few lines) Python implementation that does this and even allows for some customization: <a href="https://gist.github.com/fladd/36c422f1c0e9bf02f41f9fad19609d06" rel="nofollow">https://gist.github.com/fladd/36c422f1c0e9bf02f41f9fad19609d...</a>
Good explanation. It is a nice progress bar, but not particularly unique; many command line tools use progress bars like this.<p>I've always been curious how the Heroku CLI renders its progress bar, which is unique as far as I've seen. It does not seem to use characters, it's seemingly a smooth, pixel-based fill like you'd get in a non-terminal app. Downloading a pg backup is the most common place I see it.
I implemented something like this in bash. I called this status bar sort of implementation as "message bar" to show the ongoing status of the script on a reserved lines on bottom of the screen - I had to implement progress bar one for each task inline (and not on the bottom bar) - and constantly had to switch "states" to save/restore the cursor positions on screen.<p>This message bar would also become a prompt and take in user inputs on certain events apart from being a static status bar - super useful for the use case.<p>Cursor positions, scrolling screens, events, progress bar updates, managing child sessions, handling screen resolution changes, taking user inputs...everything had to be catered for in this.<p>I thoroughly enjoyed developing this and still think it was a bit over the board for what I was developing at the time but I was sent on this path of constant learning so couldn't look back - was worth it.<p>Here's the project: <a href="https://github.com/PrajwalSD/runSAS" rel="nofollow">https://github.com/PrajwalSD/runSAS</a>
I wouldn't call it fancy: I can't change the color so on light backgrounds I can't read it. And I've seen certain error messages slice it in two.<p>I'd call it annoying.
A lot of terminals support Unicode, so fancy can be actually fancy in such cases using block characters that produce smooth progress animation. I.e. using those from Left one eighth block to Full block.<p><a href="https://en.wikipedia.org/wiki/Block_Elements" rel="nofollow">https://en.wikipedia.org/wiki/Block_Elements</a><p>I once added such progress bar for lgogdownloader.
I use a similar approach in libmish [0], ie I "reserve" the bottom 2 rows, and output the scrolling text in the top parts. Pretty straightforward.<p>[0]: <a href="https://github.com/buserror/libmish" rel="nofollow">https://github.com/buserror/libmish</a>
I'd prefer a "Double Debian" distro that does the following:<p>1. When I run an apt command, it goes ahead and runs an automated version of the command on a "shadow" apt on the same machine.<p>2. It measures the time it took to do that operation on the shadow apt.<p>3. By the time I respond "y" to the command, it uses the duration from step 2 to display a <i>time-based</i> progress bar that animates smoothly over said duration.<p>4. If the shadow apt command hasn't finished by the time I respond "y" to the command, it brings up Ms. Pacman for me to play for a bit.<p>I bet I'd be a much more satisfied user!
Nitpick about the website, but please don't use PGP short fingerprints like 0x46EBCD72F08E6717. They can be brute forced [0] very fast to get a different private key with the same fingerprint. You can also use them to generate keys with vanity fingerprints, which is pretty funny [1].<p>[0] <a href="https://github.com/lachesis/scallion" rel="nofollow">https://github.com/lachesis/scallion</a>
[1] I have 0xDE4444AAAAAAAAAA, took me 5 minutes of bruteforcing on a laptop.