buildkite / terminal-to-html Goto Github PK

In the following line of code s.otherColors == s.otherColors should read s.otherColors == o.otherColors

return s == o || (s.fgColor == o.fgColor && s.bgColor == o.bgColor && s.otherColors == s.otherColors)

/src/github.com/buildkite/terminal/style.go:16:72: identical expressions on the left and right side of the '==' operator

It's pretty bad. I can provide test cases for anyone interested.

Background

The github.com/buildkite/terminal-to-html uses Go modules and the current release version is v3. And it’s module path is "github.com/buildkite/terminal-to-html", instead of "github.com/buildkite/terminal-to-html/v3". It must comply with the specification of "Releasing Modules for v2 or higher" available in the Modules documentation. Quoting the specification:

A package that has opted in to modules must include the major version in the import path to import any v2+ modules
To preserve import compatibility, the go command requires that modules with major version v2 or later use a module path with that major version as the final element. For example, version v2.0.0 of example.com/m must instead use module path example.com/m/v2.
https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

Steps to Reproduce

GO111MODULE=on, run go get targeting any version >= v3.3.0 of the buildkite/terminal-to-html:

$ go get github.com/buildkite/[email protected]
go: finding github.com/buildkite/terminal-to-html v3.3.0
go: finding github.com/buildkite/terminal-to-html v3.3.0
go get github.com/buildkite/[email protected]: github.com/buildkite/[email protected]: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v3

run go get github.com/buildkite/terminal-to-html, the version will stuck in v3.2.0:

$go get github.com/buildkite/terminal-to-html
go: downloading github.com/buildkite/terminal-to-html v1.0.2
go: downloading github.com/buildkite/terminal-to-html v3.2.0+incompatible
go: github.com/buildkite/terminal-to-html upgrade => v3.2.0+incompatible

SO anyone using Go modules will not be able to easily use any newer version of buildkite/terminal-to-html.

Solution

1. Kill the go.mod files, rolling back to GOPATH.

This would push them back to not being managed by Go modules (instead of incorrectly using Go modules).
Ensure compatibility for downstream module-aware projects and module-unaware projects projects

I see these dependencies in your go.mod file, which need modle awareness. So you'd better not use third-party tools(such as: Dep, glide, govendor…).

github.com/buildkite/terminal-to-html/v3

You also need to update the import path to:

import github.com/buildkite/terminal-to-html/…

2. Fix module path to strictly follow SIV rules.

Patch the go.mod file to declare the module path as github.com/buildkite/terminal-to-html/v3 as per the specs. And adjust all internal imports.
The downstream projects might be negatively affected in their building if they are module-unaware (Go versions older than 1.9.7 and 1.10.3; Or use third-party dependency management tools, such as: Dep, glide,govendor…).

If you don't want to break the above repos. This method can provides better backwards-compatibility.
Release a v2 or higher module through the major subdirectory strategy: Create a new v3 subdirectory (github.com/buildkite/terminal-to-html/v3) and place a new go.mod file in that subdirectory. The module path must end with /v3. Copy or move the code into the v3 subdirectory. Update import statements within the module to also use /v3 (import "github.com/buildkite/terminal-to-html/v3/…"). Tag the release with v3.x.y.

3. Suggest your downstream module users use hash instead of a version tag.

If the standard rule of go modules conflicts with your development mode. Or not intended to be used as a library and does not make any guarantees about the API. So you can’t comply with the specification of "Releasing Modules for v2 or higher" available in the Modules documentation.
Regardless, since it's against one of the design choices of Go, it'll be a bit of a hack. Instead of go get github.com/buildkite/terminal-to-html@version-tag, module users need to use this following way to get the buildkite/terminal-to-html:
(1) Search for the tag you want (in browser)
(2) Get the commit hash for the tag you want
(3) Run go get github.com/buildkite/terminal-to-html@commit-hash
(4) Edit the go.mod file to put a comment about which version you actually used
This will make it difficult for module users to get and upgrade buildkite/terminal-to-html.

[*] You can see who will be affected here: [12 module users, e.g., kube-score/web, buildbarn/bb-browser, csweichel/werft]
https://github.com/search?q=buildkite%2Fterminal-to-html+filename%3Ago.mod

Summary

You can make a choice to fix DM issues by balancing your own development schedules/mode against the affects on the downstream projects.

For this issue, Solution 2 can maximize your benefits and with minimal impacts to your downstream projects the ecosystem.

References

• https://github.com/golang/go/wiki/Modules#semantic-import-versioning
• https://golang.org/cmd/go/#hdr-Module_compatibility_and_semantic_versioning
• https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

Hi,

Can you please add Orange color?
fg - 38
bg - 48

Our pipelines often produce video renderings of our simulations. It would be very useful if we could embed the videos in the log output, similar to how images are handled.

--- FAIL: TestRendererAgainstCases (0.00s)
    terminal_test.go:273: renders APC escapes as processing instructions
        input		"\x1b_bk;x=llamas\\;;y=alpacas\a"
        received	"<?bk y=\"alpacas\" x=\"llamas;\"?>"
        expected	"<?bk x=\"llamas;\" y=\"alpacas\"?>"
FAIL

This spec fails intermittently, presumably due to go not guaranteeing order of several of its types.

Erase End of Line [K
Erases from the current cursor position to the end of the current line.

Erase Start of Line [1K
Erases from the current cursor position to the start of the current line.

Erase Line [2K
Erases the entire current line.

SInce we can include images, I suppose links should not be too difficult.

Proposed syntax:

printf '\033]1337;url='"$1"';content='"$2"'\a\n'

The use case would be to enrich test failure backtraces so that each line is a link to the file on GitHub.

It'd be nice to include an example of the typical setup and development workflow

This input:
out.txt

Should look like this:

(Terminal.app and iTerm 2 with standard ANSI colors)

…but looks more like this:

So the "2 - 6" has no color and the little bolts don't blink.

To repro:
Set up a buildkite pipeline that runs

npm install chalk
node -e 'console.log(require("chalk").bold("Hello World"))'

The text should be bold, but isn't.
The escape sequence used is:
ESC [ 1 m

See https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_parameters

1 Bold or increased intensity

Use case: For example, the text "Browser console:" here is supposed to be bold to make the logs easier to read

iTerm2, VS Code terminal support this.

Buildkit builds seem to rewrite the first line while continuing to output new lines at the bottom, and whatever terminal codes it's using don't seem to quite be supported here:

When I tried to install using go get:

$ go get github.com/buildkite/terminal-to-html/cmd/terminal-to-html
# github.com/buildkite/terminal-to-html/cmd/terminal-to-html
gopath/src/github.com/buildkite/terminal-to-html/cmd/terminal-to-html/terminal-to-html.go:92:17: cannot use cli.StringFlag literal (type cli.StringFlag) as type cli.Flag in array or slice literal:
	cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)
gopath/src/github.com/buildkite/terminal-to-html/cmd/terminal-to-html/terminal-to-html.go:97:15: cannot use cli.BoolFlag literal (type cli.BoolFlag) as type cli.Flag in array or slice literal:
	cli.BoolFlag does not implement cli.Flag (Apply method has pointer receiver)
gopath/src/github.com/buildkite/terminal-to-html/cmd/terminal-to-html/terminal-to-html.go:102:13: cannot use func literal (type func(*cli.Context)) as type cli.ActionFunc in assignment

$ go version
go version go1.10.4 linux/amd64

Up until recently, the tarball https://github.com/buildkite/terminal/archive/v3.1.0.tar.gz had SHA-256 sum ba8e7566a7fe5c62089fa56191c80bf15b121ae369d0c17f6f80669d3bbbb23f. All files contained were prefixed with terminal-3.1.0/.

As of recently, the link above redirects to https://github.com/buildkite/terminal-to-html/archive/v3.1.0.tar.gz. The checksum is now 5d0203bb4dd007ad607df7d0eecbe50ff4bdaa0e56e1ad2ea1eb331ff2ae5be6 and the prefix of files contained within has also changed: terminal-to-html-3.1.0/.

I'm not saying the repository should be renamed back; just wanted to give you guys a heads-up about this.

Discovered while trying to work out why our build output was coming up as if we'd hit the 1mb log limit .. and then find that instead terminal is respecting the ANSI code to clear the screen and/or the scrollback buffer.

Given the context where terminal is used, I don't think it should do this. At the very least it should instead clear the current line -- or if there's a way wrangle it in buildkite, insert a banner of some sort.

I've looked at making the code in the build not do this, but in doing so I keep finding issues like this one (facebook/create-react-app#2495) where the project author is optimising for the console experience - but when viewing the BK log we generally want the whole thing.

(edit) In our case the code is outputting a 2J - clear screen without clearing scrollback - but the way it's represented in the BK build output is to make it look like the scrollback is gone as well.

In all our Buildkite builds using sbt (the build tool for Scala projects), sbt prints this message many times during the process:

tput: No value for $TERM and no -T specified

Since I can't reproduce this any any other environment, this may be an issue with the tty used by Buildkite. Do you have any idea of what the problem might be and how can I fix it?

In order to see proper colors for the first 16 colors in the 8-bit color range, I had to add the following to my css file (based on terminal.css):

.term-fgx0 { color: #000000; }
.term-fgx1 { color: #800000; }
.term-fgx2 { color: #008000; }
.term-fgx3 { color: #808000; }
.term-fgx4 { color: #000080; }
.term-fgx5 { color: #800080; }
.term-fgx6 { color: #008080; }
.term-fgx7 { color: #c0c0c0; }
.term-fgx8 { color: #808080; }
.term-fgx9 { color: #ff0000; }
.term-fgx10 { color: #00ff00; }
.term-fgx11 { color: #ffff00; }
.term-fgx12 { color: #0000ff; }
.term-fgx13 { color: #ff00ff; }
.term-fgx14 { color: #00ffff; }
.term-fgx15 { color: #ffffff; }

I got the color codes from the wikipedia page: https://en.wikipedia.org/wiki/ANSI_escape_code#8-bit

While iTerm2 images are working, buildkite itself has a 1mb limit on build logs, which means that using the image inlining for showing screenshots of failed browser tests in builds would quickly exceed this limit.

I propose a new "standard" for referring to images that are part of the build artifacts.

The iTerm2 standard currently looks like:
\x1b[1337;File=name=1.gif;width=100%;height=50px;inline=1:BASE64\a

Ours could be:
\x1b[1338;name=output/1.gif;width=100%;height=50px\a

Notes:

• We keep iTerm2's backward escape starter of [ and ending the string with \a
• We strip the starting File= and the trailing :BASE64 section.
• We use 1338, not 1337. A significant problem with this proposal is that it is less leet.
• name is required and points to the file's location relative to buildkite's artifacts
• width and height are optionally supported
• inline is no longer required

While the iTerm2 syntax currently causes terminal to inline the image using src="data...", this would merely refer to the file on disk using a prefix that could be specified at program startup.

Porting imgcat to use this would be quite simple. Porting the iTerm2 image handling code in terminal would also be simple.

The v3.3.0 release added a go.mod and go.sum but isn't properly versioned so it cannot be used with Go Modules.

Go has a good writeup about how you need to specially handle versions 2 and greater here:

https://blog.golang.org/v2-go-modules

Attached is a sample log output from a docker pull command.

sample.txt

When you run cat sample.txt you see this:

❯ cat /Users/keithpitt/Downloads/sample.txt                                                                                                                    
+ docker push 061442450191.dkr.ecr.eu-central-1.amazonaws.com/lol/thingy:9a5a7e9
The push refers to a repository [061442450191.dkr.ecr.eu-central-1.amazonaws.com/lol/thingy]
07e62ecb726a: Layer already exists
331743f747fb: Layer already exists
2543649889c9: Layer already exists
10f91d26a1a9: Layer already exists
4dd2f6cdfbcf: Layer already exists
d75290d8c3ab: Layer already exists
a4c405a1d61b: Layer already exists
d79093d63949: Layer already exists
87cbe568afdd: Layer already exists
787c930753b4: Layer already exists
9f17712cba0b: Layer already exists
223c0d04a137: Layer already exists
fe4c16cbf7a4: Layer already exists
9a5a7e9: digest: sha256:e0271b89d75b4bf43d89eda0de850770f8f0a026fc7d7e967124cbad3d41f5d3 size: 3052

When you run it through terminal, you get:

❯ cat sample.txt | godep go run cmd/terminal-to-html/*.go
223c0d04a137: Layer already exists
fe4c16cbf7a4: Layer already exists
9a5a7e9: digest: sha256:e0271b89d75b4bf43d89eda0de850770f8f0a026fc7d7e967124cbad3d41f5d3 size: 3052%

Something weird is going on, and I believe I've tracked it down to our up handling. Specifically our A instruction here:

Now during my testing, if I added this 1 line:

The problem went away. I don't think the adding of the character is fixing the issue, but when we append a ton of other internal other stuff takes place:

I spent half a day on this on Friday, and got sucked into a wormhole. The hard thing is not knowing what the correct behaviour is in a shell. So I'll need to pair with someone this week (probably @sj26) and get it fixed up.

Similar to how buildkite/agent does it

https://github.com/buildkite/terminal-to-html/releases/tag/v3.2.0 seems to just be the git tag at the moment, not a changelog with attached binaries like https://github.com/buildkite/terminal-to-html/releases/tag/v3.1.0.

It looks like this tool used to be a Ruby library.

Where did the Ruby code go? And does it still work?

Add a checksum for an archive of a binary

It is good to have it so when we download your binary, it would be possible to validate the checksum and make sure that this binary is what we download without any issues.

Would be nice to have it.

We are using the Agent ansi-timestamps experiment, which injects timestamps into the ANSI output using Application Program Commands. These should be rendered as invisible, much like control characters. It appears this isn't happening:

When rendered directly in iTerm2, we see the correct output (even with the ansi timestamps inline):

I suspect this will be affecting lots of different types of progress bars when ansi-timestamps is enabled.

I suspect this is because the handling of the APCs is appending an element to the virtual screen, which will then increase the X count, meaning it throws out any ANSI control characters that are clearing the progress bar part way through with backspace control chars (vs erasing the whole line).

iTerm’s hyperlink format differs from that supported by us, which makes interoperability a bit weird.

iTerm 2’s links look like this:

printf '\033]8;;https://buildkite.com\aBuildkite\033]8;;\a'

Our links look like this:

printf '\033]1339;url=https://buildkite.com;content=Buildkite\a’

Valid links in Buildkite’s style don’t render at all in iTerm 2, whilst due to being surrounded by ANSI escape codes, iTerm 2’s links fall back to just being text.

Bonus points: If we felt really fancy, we could even make use of the extra provision for a key-value parameter to enable a fix for #32:

printf '\033]8;target=_blank;https://buildkite.com\aBuildkite\033]8;;\a'

This tool writes a unified diff to stdout

https://github.com/bazelbuild/bazel-gazelle#fix-and-update

I wish I could colorize it like GitHub does in their markdown flavor so added/removed regions are green/red respectively.

In the process of testing #68, I was unable to build the code in a Go 1.9 docker image. I was able to build after updating the Go image version to 1.12 in the Dockerfile and adding GO111MODULE=on as an environment variable.

It may be worth noting that I was using podman instead of docker, however I don't think that would cause this issue.

It appears as though some of the colours aren't properly rendered, and clearing the background colour doesn't actually clear the background colour. As you can see from the expected screenshot (both using the same code), the background should end after P but it continues, and the yellow text isn't being shown.

Expected:

Actual:

why? better googleability for one.

• Github handles redirects from old name just fine.
• Github routes push/pull from/to old remote namses just fine

Add some kind of ability to see the rendered output with stylesheet and all.

It could be as simple as a --layout flag which outputs the HTML container and CSS as well as the terminal output, so you can do:

mycommand | terminal --preview > /tmp/preview.html && open /tmp/preview.html

Ref: #29
So the link feature is awesome:

One little downside: I wish I could specify target="_blank" because output pages are quite big and take a while to load, so it's a bummer when you forget to open the link in a new tab and that you have to load the output page again after.

@toolmantim @keithpitt @mipearson what do you think?

I tried to implement it myself, but my go is really not good :/

http://www.iterm2.com/images.html

failed MSpanList_Insert 0x535000 0x17258359846e 0x0
fatal error: MSpanList_Insert

runtime stack:
runtime.throw(0x4ac06b)
	/usr/src/go/src/runtime/panic.go:491 +0xad fp=0x7ffeefbff1c0 sp=0x7ffeefbff190
runtime.MSpanList_Insert(0x4d2648, 0x535000)
	/usr/src/go/src/runtime/mheap.c:692 +0x8f fp=0x7ffeefbff1e8 sp=0x7ffeefbff1c0
MHeap_FreeSpanLocked(0x4cf240, 0x535000, 0x100)
	/usr/src/go/src/runtime/mheap.c:583 +0x163 fp=0x7ffeefbff228 sp=0x7ffeefbff1e8
MHeap_Grow(0x4cf240, 0x8, 0x0)
	/usr/src/go/src/runtime/mheap.c:420 +0x1a8 fp=0x7ffeefbff268 sp=0x7ffeefbff228
MHeap_AllocSpanLocked(0x4cf240, 0x1, 0x0)
	/usr/src/go/src/runtime/mheap.c:298 +0x365 fp=0x7ffeefbff2a8 sp=0x7ffeefbff268
mheap_alloc(0x4cf240, 0x1, 0x12, 0x0)
	/usr/src/go/src/runtime/mheap.c:190 +0x121 fp=0x7ffeefbff2d0 sp=0x7ffeefbff2a8
runtime.MHeap_Alloc(0x4cf240, 0x1, 0x10000000012, 0xfb39)
	/usr/src/go/src/runtime/mheap.c:240 +0x66 fp=0x7ffeefbff308 sp=0x7ffeefbff2d0
MCentral_Grow(0x4d6fb8, 0x0)
	/usr/src/go/src/runtime/mcentral.c:197 +0x8b fp=0x7ffeefbff370 sp=0x7ffeefbff308
runtime.MCentral_CacheSpan(0x4d6fb8, 0x0)
	/usr/src/go/src/runtime/mcentral.c:85 +0x167 fp=0x7ffeefbff3a8 sp=0x7ffeefbff370
runtime.MCache_Refill(0x531000, 0x12, 0x0)
	/usr/src/go/src/runtime/mcache.c:90 +0xa0 fp=0x7ffeefbff3d0 sp=0x7ffeefbff3a8
runtime.mcacheRefill_m()
	/usr/src/go/src/runtime/malloc.c:368 +0x57 fp=0x7ffeefbff3f0 sp=0x7ffeefbff3d0
runtime.onM(0x3c5130)
	/usr/src/go/src/runtime/asm_amd64.s:273 +0x9a fp=0x7ffeefbff3f8 sp=0x7ffeefbff3f0
runtime.mallocgc(0x120, 0x31bb80, 0x0, 0x0)
	/usr/src/go/src/runtime/malloc.go:178 +0x849 fp=0x7ffeefbff4a8 sp=0x7ffeefbff3f8
runtime.newobject(0x31bb80, 0x531000)
	/usr/src/go/src/runtime/malloc.go:353 +0x49 fp=0x7ffeefbff4d0 sp=0x7ffeefbff4a8
runtime.newG(0x28faa)
	/usr/src/go/src/runtime/proc.go:233 +0x2a fp=0x7ffeefbff4e8 sp=0x7ffeefbff4d0
allocg(0x4bfc20)
	/usr/src/go/src/runtime/proc.c:925 +0x1f fp=0x7ffeefbff4f8 sp=0x7ffeefbff4e8
runtime.malg(0x8000, 0x4bfde0)
	/usr/src/go/src/runtime/proc.c:2106 +0x1f fp=0x7ffeefbff528 sp=0x7ffeefbff4f8
runtime.mpreinit(0x4c0400)
	/usr/src/go/src/runtime/os_darwin.c:137 +0x27 fp=0x7ffeefbff540 sp=0x7ffeefbff528
mcommoninit(0x4c0400)
	/usr/src/go/src/runtime/proc.c:201 +0xc9 fp=0x7ffeefbff568 sp=0x7ffeefbff540
runtime.schedinit()
	/usr/src/go/src/runtime/proc.c:138 +0x55 fp=0x7ffeefbff590 sp=0x7ffeefbff568
runtime.rt0_go(0x7ffeefbff5c8, 0x1, 0x7ffeefbff5c8, 0x0, 0x0, 0x1, 0x7ffeefbff7e0, 0x0, 0x7ffeefbff81b, 0x7ffeefbff84c, ...)
	/usr/src/go/src/runtime/asm_amd64.s:95 +0x116 fp=0x7ffeefbff598 sp=0x7ffeefbff590

This issue appears to be fixed by some combination of Go 1.9 and building on High Sierra.

Cursor Up [{COUNT}A
Moves the cursor up by COUNT rows; the default count is 1.

Cursor Down [{COUNT}B
Moves the cursor down by COUNT rows; the default count is 1.

Cursor Forward [{COUNT}C
Moves the cursor forward by COUNT columns; the default count is 1.

Cursor Backward [{COUNT}D
Moves the cursor backward by COUNT columns; the default count is 1.

Erase Down [J
Erases the screen from the current line down to the bottom of the screen.

Erase Up [1J
Erases the screen from the current line up to the top of the screen.

Erase Screen [2J
Erases the screen with the background colour and moves the cursor to home.

So imgcat.sh and the iTerm standard expect the filename to be base64 encoded:
http://iterm2.com/images.html#/section/home

$ ./utils/imgcat.sh fixtures/meme.png | less
ESC]1337;File=name=Zml4dHVyZXMvbWVtZS5wbmc=;size=55110;...

But it seems we expect it to be plain text:

$ ./utils/imgcat.sh fixtures/meme.png | terminal-to-html 
*** Error parsing iTerm2 image escape sequence: can't determine content type for "Zml4dHVyZXMvbWVtZS5wbmc=&q

https://github.com/buildkite/terminal/blob/0f479d49667660a99390bfb7a601f50a4e36fe0f/image.go#L44

I believe all we need to do base64 decode the name field value before we set it.

I've added an example called "pikachu.ansi". Currently, it doesn't output the colors, not sure why yet. I think theres some color merging stuff in ANSI that I don't know about yet.

cc @sj26 @keithpitt

The problem (as described to me by @keithpitt) is terminal (and its ecosystem) need to support the common use case of being able to see output as it happens, including being able to display in-browser those clever npm/yarn/docker spinners and progress bars and so forth.

Keith and I discussed a few ideas:

Move the whole thing to JavaScript

BK sends the browser raw ANSI, the browser parses it and displays it to the user. Bor-ing.

terminal parses the ANSI, the browser interprets it

Terminal is responsible for parsing the ANSI and turning it in to a set of instructions (eg left; up; color 3; write bob) that are then sent to the browser for interpretation.

terminal parses the ANSI and renders it, sends browser individual lines

Terminal parses the ANSI, renders it to an internal buffer, and at a set interval (once per second? faster? when a certain amount of input is read?) sends the lines to the browser. The browser receives the lines and either adds them to the DOM (if it's a new line) or replaces it (if it's an existing line).

Terminal would stream JSON blobs (with one blob per newline) that would look something like this:

{ line: 1, html: "<span class=..." }
...
{ line: 50, html: "Loading.. 10%" }
{ line: 50, html: "Loading.. 20%" }
{ line: 50, html: "Loading.. 30%" }

My command line tool values proper typography, and so it uses curly quotes (“ ” ‘ ’) whenever appropriate ;-)

However, this causes output in the build log like ���foo��� when I expect “foo”. Can that be fixed?

Ref: #29

So I tried to use the new links, but unfortunately my plan was to use it to improve our test failure backtraces with links to GitHub. Ultimately it would work, but I'm not willing to lose the backtrace colorization I put in place:

Not sure what the best syntax would be to chose the link color. Ideally I could use regular ANSI color code in it:

echo -e '\033]1339;url=https://google.com/;content=\033[33mHello World\033[0m\a'

But here's what it gives me right now

@keithpitt @toolmantim @mipearson do you guys think it makes sense or am I pushing it?

We are using tput to handle escape codes for us, for example:

has_tty() {
  stty 2>/dev/null >/dev/null
}

ansi_header() {
  if has_tty ; then
    echo
    echo >&2 -e "$(tput sgr 0 1)$(tput bold)$(tput setaf 4)--- $@$(tput sgr0)"
  fi
}

ansi_success() {
  if has_tty ; then
    echo >&2 "$(tput setaf 2)$@ ✔$(tput sgr0)"
  fi
}

ansi_failure() {
  if has_tty ; then
    echo >&2 "$(tput setaf 1)$@ ✗$(tput sgr0)"
  fi
}

it seems that tput sgr0 outputs ESC[m, rather than the `ESC[0m'. Apparently in absence of the 0 value, 0 should be assumed.

The result of this is that our ansi styles aren't correctly reset when converted to html.

would love this available using

brew install terminal-to-html

would support updates to the compiled binaries for darwin using brew upgrade along with all my other dev tools.
could do the same thing for windows using chocolatey and linux using apt

Currently, the output renders like this:

some text <span class="c123">and this
this is colored</span>

The problem with this approach, is that if you wanted to wrap each line in a <div>, we've just broken our markup.

<div>some text <span class="c123">and this</div>
<div>this is colored</span></div>

If we have colors that span multiple lines, we should include <span> elements on each line, line so:

some text <span class="c123">and this</span>
<span class="c123">this is colored</span>