curl / Mailing Lists / curl-users / Single Mail


Re: Feedback wanted: bold headers? (Daniel Stenberg et al)

From: Timothe Litt <>
Date: Sun, 29 Apr 2018 07:33:24 -0400

On 29-Apr-18 06:00, wrote:
> Message: 1
> Date: Sat, 28 Apr 2018 13:34:42 +0100
> From: Jeremy Nicoll <>
> To:
> Subject: Re: Feedback wanted: bold headers?
> Message-ID:
> <>
> Content-Type: text/plain; charset="utf-8"
> On Fri, 27 Apr 2018, at 23:26, Daniel Stenberg wrote:
>> 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
(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 | \
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 | \
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.


Received on 2018-04-29