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

Spaceship loading bar breaks on wide terminal widths #12407

Closed
timhillgit opened this issue Nov 27, 2023 · 1 comment
Closed

Spaceship loading bar breaks on wide terminal widths #12407

timhillgit opened this issue Nov 27, 2023 · 1 comment

Comments

@timhillgit
Copy link

I did this

I used curl inside of a terminal with a large width (300) to download a file while displaying the loading bar. I tested in both macOS Terminal and iTerm.

I expected the following

The spaceship would be cleared after the file was downloaded, replaced by the full progress bar. The spaceship and progress bar will take up one line total. Instead I saw the following:
Screenshot 2023-11-12 at 23 32 16
The progress bar is capped at a maximum length of 256 but the spaceship flies past that limit and isn't cleared.

curl/libcurl version

Default macOS curl:

curl 8.1.2 (x86_64-apple-darwin23.0) libcurl/8.1.2 (SecureTransport) LibreSSL/3.3.6 zlib/1.2.12 nghttp2/1.55.1
Release-Date: 2023-05-30
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL threadsafe UnixSockets

I've also tried the homebrew install of curl and saw the same results:

curl 8.4.0 (aarch64-apple-darwin23.0.0) libcurl/8.4.0 (SecureTransport) OpenSSL/3.2.0 zlib/1.2.12 brotli/1.1.0 zstd/1.5.5 libidn2/2.3.4 libssh2/1.11.0 nghttp2/1.58.0 librtmp/2.3 OpenLDAP/2.6.6
Release-Date: 2023-10-11
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz MultiSSL NTLM SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd

operating system

macOS Sonoma 14.1.1

bagder added a commit that referenced this issue Nov 27, 2023
When the progress bar was made max width (256 columns), the fly()
function attempted to generate its output buffer too long so that the
trailing carriage return would not fit and then the output would show
wrongly. The fly function is called when the expected total transfer is
unknown, which could be one or more progress calls before the actual
progress meter get shown when the expected transfer size is provided.

This new take also replaces the msnprintf() call with a much simpler
memset() for speed.

Reported-by: Tim Hill
Fixes #12407
@bagder
Copy link
Member

bagder commented Nov 27, 2023

It is the initial output that gets written without the carriage return due to math mistakes. I made #12415 that should fix that mistake. It seemed to do it in my tests.

@bagder bagder closed this as completed in e6bf200 Nov 27, 2023
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

2 participants