Commit
Get screen width from the environment variable COLUMNS first, if set. If not, use ioctl(). If nether works, assume 79. Closes #2242 The "refresh" is for the -# output when no total transfer size is known. It will now only use a single updated line even for this case: The "-=O=-" ship moves when data is transferred. The four flying "hashes" move (on a sine wave) on each refresh, independent of data.
- Loading branch information
There are no files selected for viewing
7 comments
on commit 993dd56
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A set COLUMNS=120
and a:
curl -o NUL -# rtmp://cp67126.edgefcs.net/ondemand/mp4:mediapm/ovp/content/test/video/spacealonehd_sounas_640_300.mp4
causes this Windows console wrap-error:
-=O=- # # ##
-=O=- # ###
-=O=- ####
-=O=- # ##
-=O=- # # ##
With a set COLUMNS=119
, all seems okay. And yes my console is 120 columns wide.
You tested this in bash? Which behaves differently when write a character at right edge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've made a patch for Windows (doesn't rely on COLUMNS
):
--- a/tool_cb_prg.c 2018-01-23 18:34:35
+++ b/tool_cb_prg.c 2018-01-23 20:33:11
@@ -202,6 +202,20 @@
struct winsize ts;
if(!ioctl(STDIN_FILENO, TIOCGWINSZ, &ts))
cols = ts.ws_col;
+#elif defined(_WIN32)
+ {
+ HANDLE stderr_hnd = GetStdHandle(STD_ERROR_HANDLE);
+ CONSOLE_SCREEN_BUFFER_INFO console_info;
+
+ if ((stderr_hnd != INVALID_HANDLE_VALUE) &&
+ GetConsoleScreenBufferInfo(stderr_hnd, &console_info)) {
+ /*
+ * Do not use +1 to get the true screen-width since writing a character at
+ * the right edge will cause a line wrap.
+ */
+ cols = (int) (console_info.srWindow.Right - console_info.srWindow.Left);
+ }
+ }
#endif /* TIOCGSIZE */
bar->width = cols;
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good. I had a hard time finding an URL which total transfer size is unknown. Do you have an rtmp stream with truly infinite size? I used this Chinese one rtmp://ossrs.net/live/livestream
, but that host is down.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I had that problem too. I couldn't find any good URL that reliably would send something decently large without a size. I ended up setting up a hacky local HTTP server that respond without size, and then I could use --limit-rate
to make it go on for a longer time than it would otherwise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I couldn't find any good URL that reliably would send something decently large without a size.
curld -v -# -H "Connection: close" --ignore-content-length "http://httpbin.org/drip?numbytes=10485760&duration=5&delay=0&code=200" -o NUL
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haha, that's just a lovely use of curl. You rock @jay!
Shouldn't this be
fputs(buf, bar->out);
?