Timothe Litt
2018-04-29 11:33:24 UTC
Message: 1
Date: Sat, 28 Apr 2018 13:34:42 +0100
Subject: Re: Feedback wanted: bold headers?
Content-Type: text/plain; charset="utf-8"
I'm not sure - it seems like feature overload. But maybe. It's a stepDate: 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'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.
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 thehaven't made any such yet.
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?
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.