I can't seem to figure out why this happens or even what to search for.

Two videos demonstrating the issue:

  1. https://www.loom.com/share/7497428d757e45399faa5ebcf391e1be
  2. https://www.loom.com/share/456944568b3b4eb4ac563cd6c4a6fc03

Basically when pressing a delete key or backspace while editing in vi I get this garbled junk:

^@?^D?@I_?^@S܅^@^@^@^@ M-?pK_?pK_?^P^@^@^@
^@^@^@?7C^@^@2C^@?,C^@?,C^@?,C^@@7C^@^A^\^@^P^F^@^@^@@I_?^@S܅^@r???^V^X?^@^@^@^@?c-?^@^@^@^@^F^@^@^@` Z?@I_?@I_?^T62?^@^@^@^@$?%?^H???^@^@^@^@^@^@^@^@^@^@^@^@%^B^@^@^@^@^@
# uname -a
Linux openmiko 3.10.14 #1 PREEMPT Sun Nov 1 02:58:54 UTC 2020 mips GNU/Linux
# env
SSH_CLIENT= 65524 22

I thought it was because I disabled wchar support but that wasn't it.

I can't seem to reproduce this in a new file. However editing an existing file seems to trigger it. This is all in a zram system.

I am using vi to test which is compiled with busybox.

# vi -h
BusyBox v1.24.1

It looks like when I create a new file and paste into it using vi it works fine. When I write it out it writes properly. However when I edit it again I get the corruption.

  • 2 ideas: file encoding vs locale; broken RAM. Nov 22, 2020 at 10:25
  • The edit is not even near the cursor in the video -- it is about six lines down, and seems to have inserted about 200 bytes of binary data (those ^@ are a vi representation of NUL (\000) characters). I'm suspecting you may have inadvertently recorded a macro in vi, or have preceded some intended vi command with a : (ed command prefix) or ! (shell command prefix). Or your (Mac?) keyboard mapping are doing some unexpected translations. Nov 22, 2020 at 10:55
  • Does this happen on all files; all terminals; all sessions? Test on a new simple file. I am considering whether these characters are ncurses control strings, and either the TERM setting or the terminfo data is illegal for the actual terminal type that vi is addressing. Is this a remote session, by any chance? Nov 22, 2020 at 12:46
  • This is on MIPS architecture with a custom compiled kernel and buildroot. Linux openmiko 3.10.14 #1 PREEMPT Sun Nov 1 02:58:54 UTC 2020 mips GNU/Linux
    – Jeff T
    Nov 22, 2020 at 16:52
  • @ctrl-alt-delor I do not think it is file encoding because I am editing the files directly on the device. Broken RAM is possible but other people have flashed this kernel and experiencing same thing.
    – Jeff T
    Nov 22, 2020 at 16:58

1 Answer 1


While I cannot affirm: "The on your specific case, is caused by X", specially considering I'm not able to fully reproduce your environment, I think I am able[a] to guide you on an informed search for the problem. Probably it's not the answer you'd expect, but I think you won't find much unless someone with proper knowledge is able to reproduce your environment. Therefore I'll try to discuss a wide range of factors potentially affecting your use of the tool, so you might find the problem yourself.

Initial Considerations

There are some details that might seem irrelevant but likely have an impact on what you are experiencing.

1. Busybox vi is not ex-vi

Talk about vi is tricky because one name might refer to dozens (or maybe hundreds) of different things. When Bill Joy stopped maintaining it lots of different people started working on it and maintaining it separately, and this is where several different vis exist. And obviously, what applies to one might not apply to the other.

Furthermore, at some point vi "clones" started to emerge, like ELVIS. And by clone it means it's a completely different codebase. So, I personally use the term vi to refer to the ex-vi, the original codebase with some later updates by Gunnar Ritter. But different people might use the term for different things, so it's important to specify.

From the top of the editors/vi.c file in Busybox's source code:

 * tiny vi.c: A small 'vi' clone
 * Copyright (C) 2000, 2001 Sterling Huxley <[email protected]>

That means what you're running is not actually what I would call vi, but a "small vi clone". It's certainly expected to affect your experience. Also, take into account that BusyBox is made for minimalist systems, therefore their vi clone might not be the most capable of handling much terminal variation.

2. There is a chain of terminal support requirements at play

You are running it into an xterm with colors (TERM=xterm-256color), which might or might not be a problem. The ex-vi could be compiled with termcap, curses or ncurses as TERMLIB, and depending on the option it would support or not an xterm terminal type. Since ncurses is modern and uses terminfo, it would likely work provided that the system has the terminal information for it. But termcap is an old and outdated terminal information database, so it would very likely explain your problems if it was the case.

But since you're not running ex-vi, you'll have to research the environment busybox-vi is providing you. I had an overview of the specific vi.c code at busybox's repository and saw no treatment for terminal in there. I would guess busybox handles terminals somewhere else, but hadn't the time to learn more about.

3. vi has no support for some keys you're using

Excluding vi clones like vim, ex-vi has no support for control keys like Del, Home, etc. So, since you related using them, this might be a source of problem. Many people might think ex-vi supports them because they use or have used it and they worked, but that's the case when using a patched version (linux distributions often patch this kind of old package, and ArchLinux, for instance, patches the vi package to support control keys.

Again, I could not find anything treating such keys in busybox's vi.c code, so we don't know for sure if it's supported by busybox somewhere else or not. Remaining the doubt, one thing you might try to do is using the x key (erases the next character) as a replacement for Del, for instance, and see if the problem happens. Or find this information for sure at busybox's docs.

Possible Causes

Now, based on the earlier considerations, let's discuss possible problems. The below list is shorter with more specific and objective possible problems to check.

1. Terminal emulation issues

As mentioned by me and by others in the comments section, the terminal information busybox vi has access to might not support or have information on the kind of terminal you are using. One thing you could try is to use an actual console instead of a graphical terminal emulator, if your OS supports it. Also, if busybox's vi is compiled with support for 'terminfo' or a library supporting it, you might try exporting the terminal information on your local system and importing at the target (though I'm not sure the platform difference might have any impact on that). If you're running Mac as suggested by some comments I cannot help you, but if you're running linux you might wanna adapt these instructions to your case.

2. Program's support for control keys

As mentioned, even with proper terminal information support, busybox's vi might not support such keys. Or, it might support but need proper configuration, so a review on busybox building config might be worth a check too.

If that's the case, you might want to file a feature request through their appropriate channels for that. They might evaluate if it fits their scope and requirements and possibly implement it (or not). Or, just use the standard keys if that's okay for you.

3. It might be a bug

Before thinking you might have RAM issues as suggested in the comments, it might be considered the possibility of a bug too. Software bugs are often more likely than hardware failure. If you don't find the cause, and if it it's reproducible like you mentioned, this is a possibility to consider. If you don't find anything in the documentation and all other possibilities are exhausted, I'd recommend filing a bug report.

The busybox's vi receive few commits per year, it might be the case that it receives no much maintenance for whatever reason.

4. Encoding Issues?

I have noticed the encoding issues being dismissed in the comments. While I find it somewhat difficult, I'm not 100% sure it can be ruled out. While the text seems to be ASCII (and therefore supported in UTF-8, for instance), there's no LANG or other locale-related environment variable set. It means that, if by any chance, your target system uses another encoding as default and it's anyhow incompatible, it might have some influence. I think it's unlikely, but relevant to mention. You might want to test running it with a LANG=en_US.UTF-8 like environment variable.

Given the above, this list is obviously not exhaustive at all. Maybe adding more info into the comments might help me or someone else to notice and add other possible causes.


[a] As someone who spent ~10 years using vi in the past (I only switched to vim near 2012), I have seen this kind of problem millions of times. Your case seems to be different, though. Anyway, I feel compelled to answer this question.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .