Running Caddy breaks terminal, ANSI escape codes are printed

[LachlanArthur]

After running Caddy with any command, the terminal breaks.
Non-printable keys print their ANSI escape sequence instead, (e.g. up arrow prints ^[[A and ctrl+c prints ^C).

OS: Windows Server 2016 Datacenter (Version 10.0.14393, Build 14393)
Caddy Version: v2.4.3 h1:Y1FaV2N4WO3rBqxSYA8UZsZTQdN+PwcoOcAiZTM8C0I=

This happens with both Command Prompt and PowerShell (v5).
I have a separate installation of PowerShell 7 that is unaffected.

This looks like the same issue as #4212

[francislavoie]

I don't have this issue using https://www.microsoft.com/en-us/p/windows-terminal/9n0dx20hk701. I recommend you use that instead.

I'm worried that any fix we implement would involve filtering the output of all commands, which I don't think I'd be comfortable with doing. I think a more modern terminal should be used instead.

[mholt]

How is printing the version string breaking the terminal? I don't understand, since this doesn't happen on any terminal I've used on multiple OSes. Sounds like a broken terminal, I'm not sure why any future input commands should ever be allowed to be corrupted by simply printing an ASCII string.

[richieadler]

How is printing the version string breaking the terminal? I don't understand, since this doesn't happen on any terminal I've used on multiple OSes. Sounds like a broken terminal, I'm not sure why any future input commands should ever be allowed to be corrupted by simply printing an ASCII string.

It's not actually the printing of the version what causes the terminal to stop breaking. I have the same problem (Windows 10, Build 19041.1083) Any execution of caddy in a terminal window for any command has the same result.

This happens in cmd and in other command prompts like TCC/Take Command.

[mholt]

Hmm, well it doesn't happen with Windows Terminal, so there's probably something about the other command prompt apps -- or something funky in Windows -- that is causing it.

(I don't use Windows so I can't help with this.)

[simaotwx]

When something like this happens on my Linux boxes, regardless of which program I run, I just run "reset" and then everything works again. Not sure if there's something like that on Windows. This is the PowerShell terminal so there must be something wrong about that I'm guessing.

[JustinWebDev]

I've been meaning to log the same issue. If you do anything with the Caddy EXE the terminal is hosed.

[egonelbre]

Dependency https://github.com/smallstep/cli-utils/blob/17e7ebecb8b9cc1cbf7958a2dcd69a63af8f710c/ui/ui_windows.go#L10 enables virtual terminal input and processing but never restores it.

[francislavoie]

PRs welcome @egonelbre, if you can determine a fix

[egonelbre]

The solution is either:

1. remove the dependency,
2. remove the init code from the dependency,
3. add code that reverts the console mode at the end of the program.

Unfortunately, don't have time to dig deeper to implement the solution. It was more of a drive-by debugging, since I've seen similar issues before.

[mohammed90]

Can any of the impacted users verify the fix in the PR #4369? You can grab the CI build artifact from here: https://github.com/caddyserver/caddy/actions/runs/1301313398#artifacts

[mholt]

Thank you very much for investigating and chiming in, @egonelbre! I prefer option 2 personally. Thanks for the patch though Mohammed, but in the nicest way possible I hope we don't have to use it. 😂

[maraino]

@mholt @francislavoie Replacing replacing go.step.sm/cli-utils should fix it.

replace go.step.sm/cli-utils => go.step.sm/cli-utils v0.6.0

We will merge smallstep/certificates#719 soon too. When this happens go get github.com/smallstep/certificates@master && go mod tidy will also fix the issue

[francislavoie]

Thanks! We'll wait for smallstep/certificates, we're not in a rush 👍

[mholt]

This is so great, thank you very much @maraino!

[LachlanArthur]

I tested the dev build and the issue has been fixed.