Discussion:
Feedback wanted: bold headers? (Daniel Stenberg et al)
(too old to reply)
Timothe Litt
2018-04-29 11:33:24 UTC
Permalink
Raw Message
Message: 1
Date: Sat, 28 Apr 2018 13:34:42 +0100
Subject: Re: Feedback wanted: bold headers?
Content-Type: text/plain; charset="utf-8"
Hi,
I've put together a little proof of concept PR that shows how curl can output
HTTP headers using bold font style for the name parts when the output is sent
to the terminal. Personally I think it helps making the headers easier to
read.
I agree...
I'm not sure - it seems like feature overload.  But maybe.  It's a step
down a path away from a
pure command line tool; you shouldn't take it without a clear view of
the end state.

This idea is more complicated to get right than it seems.
I presume we need an option to all users to explicitly turn it on/off, but I
haven't made any such yet.
Assuming that the bold feature is acheived with control codes enclosing the
bold parts of the text, I think it would need to be possible to turn it off, for
users who pipe terminal output elsewhere for subsequent processing.
Are there any OSes whose terminals don't honour these control codes?
Presumably those who explicitly direct such output to named files wouldn't
see the control codes?
Use termcap.  Or (n)curses.  Don't hardcode even the ANSI bold
controls.  Termcap has
the correct control codes for a very large set of terminals.  And a user
can use a private
library for their own - or for accessibility.  And turning off becomes a
matter of setting
your terminal type.  Further, termcap gives you the terminal width,
height, cursor
controls, strings sent by cursor/function keys, bell - whatever you
might need.

(n)curses uses termcap, and provides windowing.  So if you go down this
GUI path, you
can set up multiple scrolling regions for progress on parallel transfers
- or whatever strikes
your fancy.  Multiple pages debug info?  Scrolled headers?

Both are highly portable.  You really DON'T want to embed control
codes.  Terminals are
notorious for non-uniform (and non-standard) edge case behavior.  Once
you start
embedding controls in your code, you're on the path to an endless stream
of special
cases.  Which windows console?  The original DOS console?  The one with
ANSI.SYS?
(That isn't really ANSI.)  The windows 10 one?  A Putty window?  An
xterm?  The
Linux console?  They're all different.  Not to mention a Braille
display, or a paper terminal
(yes, I still have one of those).

Make sure that you don't break copy and paste.  Paste into a program
better be plain
text.  Paste into a bug report or manual might want to be highlighted.

Anything beyond <CR> overprinting for a progress bar should use
termcap.  (and even
that has corner cases - like what happens at the margin - autowrap?
stuck in last column?)

While auto detecting output to a non-TTY such as a pipe seems like a
good idea, it doesn't
always work.  Consider the case of several screenfulls of headers
(pretty common with
CDNs).  So one pipes them to a pager.  If you want emphasis at all, you
want it there.
See ls --color=WHEN and less -R for some previous (not alltogether
sucessful, but usable)
work.  OTOH, piping to grep, sed, nc, or perl - or redirecting to a file
almost always breaks.
You don't know what's on the other end.

Do you want curl to have a GUI?

If not, for a trivial alternative to the initial proposal, use this:

2>&1 curl -v http://www.spamhaus.org/drop/dropv6.txt | \
sed -e's/^< \([A-Z}[A-Za-z-]*:\)/< \x1b[1m\1\x1b[m/' | less -R

Taking my own advice to use termcap results in:
B="`tput bold`"
b="`tput sgr0`"
2>&1 curl -v http://www.spamhaus.org/drop/dropv6.txt | \
sed -e"s/^< \([A-Z}[A-Za-z-]*:\)/< $B\1$b/" | less -R



Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
Daniel Stenberg
2018-04-29 21:49:01 UTC
Permalink
Raw Message
I'm not sure - it seems like feature overload.  But maybe.  It's a step down
a path away from a pure command line tool; you shouldn't take it without a
clear view of the end state.
I've never had a clear view of that before but that doesn't usually stop me. I
don't even think there *is* an end state for curl. It's a journey that never
ends.
Use termcap.  Or (n)curses.  Don't hardcode even the ANSI bold controls.
That would be taking things (much) further than I'd be comfortable with.
Make sure that you don't break copy and paste.
How would I break or not break that?
Do you want curl to have a GUI?
No.
2>&1 curl -v http://www.spamhaus.org/drop/dropv6.txt | \
sed -e's/^< \([A-Z}[A-Za-z-]*:\)/< \x1b[1m\1\x1b[m/' | less -R
Of course that breaks in 22 different ways when you add other factors in. But
sure, that works for the simple use case.
I'd find that to be a too huge penalty for just doing bold escape codes.
--
/ daniel.haxx.se
Loading...