3

I had just installed coverage and run it a few times when I noticed a .coverage file hanging around in my repo, which is -- according to the file utility -- a 8086 relocatable (Microsoft) file. And then I did this, because I had no idea what it was and wanted to know what was inside it...

~/repos/personalsite(master 7↑)$ cat .coverage
...lots of output...
≤☃─☃┼±@≤⎽☃└:·/⎼e⎻⎺⎽/≤☃─☃┼±⎽☃└↓c⎺└/≤☃─☃┼±⎽☃└(└▒⎽├e⎼ 7↑)$ 

Even when I pressed Enter a couple times it remained like that. Not only that, when I typed into the command line, characters that I didn't expect showed up, e.g.

$ ↓┘ ┼⎺├ ⎺┼┌≤ ├▒▒├┬▒≤ ☃⎽ ├▒e⎼e ┼⎺├

The only solution was for me to close the (tmux) window. I'm just wondering (a) why this happened, and (b) if there's any way to fix this next time I happen to do this?

3

For question a): this depends on which type of terminal you have. Just do a echo $TERM to see which type of terminal you have. xterm should be fine. I had this problem a lot when connecting via serial console and the only working type of terminal was vt100 (an old but very compatible terminal). Also when changing $TERM to vt100 via SSH I had the same problem.

for question b): executing the command reset should do the trick. Maybe you see the command also in gibberish but it should work.

Just for clarification: this happens every time you try to do cat on a binary encoded file, not specially .coverage files.

| improve this answer | |
  • Or use stty sane. – LawrenceC Oct 16 '13 at 21:14
  • Using "reset" fixed the issue on a Check Point firewall console from expert mode. THANK YOU noggerl! – David Oct 1 '15 at 2:09
1

The literal character ^N can cause this behavior on certain terminals when printed. cat printed that character when trying to read the binary encoded file.

To reproduce this behavior, you can write the ^N character to a file using literal character entry in vi. Open vi, enter Ctrl-vCtrl-n in insert mode, and save the file. If you cat this file, your terminal's encoding will be borked.

The literal character ^O reverses this behavior, and can be written in vi by entering Ctrl-vCtrl-o.

| improve this answer | |
  • Thank you! I tried to diff two .vimrc files and got into this state. Typing Ctrl-v Ctrl-o Enter on the command line fixed it. Wow. (reset also fixed it, but I prefer this solution). – gilly3 Mar 22 '18 at 16:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.