I'm trying to ssh to FreeBSD-11.2-Release from my Windows machine using Mintty, but when I set LC_ALL to en_US.UTF-8 and try to enter/paste a non-ASCII character, connection got closed.

I'm using Cygwin, and have also tried Qterminal and Terminator.

Does FreeBSD have a problem with UTF-8 characters at 11.2-Release version? Or is this just Windows-specific (by which I mean macOS or Linux users have no issue with it)?

Note: I don't have any window system installed on the FreeBSD machine.

  • Cross posted a PR at bugs.freebsd.org
    – DannyNiu
    Nov 30, 2018 at 2:08
  • 1
    In the PR you refer to my answer here and state it needs to be set per user. You can do a system wide change with the "default" class in login.conf Dec 1, 2018 at 8:47

1 Answer 1


You claim setting LC_ALL but I am not sure you are doing it correctly. Everything is actually covered in The FreeBSD Handbook: 22.2. Using Localization

I would strongly recommend that you use the "Login Classes Method" (login.conf) rather than the "Shell Startup File Method" (.profile) as it is much more consistent across the system and shells.

When people then say they have modified language related settings they often forget 2 things:

  1. When changing either /etc/login.conf (system wide) or ~/.login.conf (user) you need to run cap_mkdb to have any effect!
  2. And when testing remember to start a new session!

The first thing is to verify your settings by running the command locale. On a vanilla FreeBSD system it will show you this:

$ locale

With these settings, you will have Unicode problems with the most common terminals. I am using PuTTY, but am not able to paste the following test into the terminal:

ÆØÅ жз ઑ ᱵ

This is because the default setting of FreeBSD is not to use unicode. This answer was tested against 11.2 but in the future from 13 and onwards the default will be "C.UTF8" and no change will be needed. On a vanilla install you can, however, make a very quick check by setting your user to use "russian". The reason is that russian is the only language defined out of the box (in /etc/login.conf) and it is using unicode.

pw usermod johndoe -L russian

Now login to a new session using the "johndoe" account (whatever your user is named). You will now be able to paste unicode (from the test above) into the shell. Verify how the settings has been picked up using locale

$ locale

As I now have verified that basic unicode actually works - then I can start setting things to my liking. As I am danish, I will perform the following simple steps:

1. Add language settings

For each language I need I will add a section to /etc/login.conf

danish|Danish Users Accounts:\

2. Update database

Whenever you edit the source login.conf, you need to update the database.

cap_mkdb /etc/login.conf

3. Set user languages

I usually use pw to manage my users. Now I just need to specify the language when I create or modify my users.

pw useradd janedoe -L danish

TIP: My personal preference is to not change the system wide "default" but keep it as default. Then I set the language for system accounts such as "postgres". If you have very specific settings needed for a system account not covered by your language setting, then I would create a separate "language" (login class) for that account in /etc/login.conf. This keeps things nice and tidy.

TIP 2: The above shows how to set class on user basis. If you want a system wide change you can change the "default" class in login.conf.

PuTTY TIP: Your terminal naturally needs to be UTF-8 aware as well. In PuTTY this is in the settings: Window ⮕ Translation. I have mine set to "UTF-8". If you are in the CJK area you might want to check "Treat CJK ambiguous characters as wide". And Cyrillic users usually likes "Caps Lock acts as Cyrillic switch".

  • Does work in the version I'm using. I heard it got fixed in 13-CURRENT.
    – DannyNiu
    Nov 30, 2018 at 1:31
  • 1
    @Claus, thanks for the detailed answer. In response to "This is because the default setting of FreeBSD is not to use unicode," I think it was mostly a momentum and political problem. The default locale has always been and will be "C." Unfortunately, there was no UTF-8 C locale until very recently and as you can imagine, it is politically insensitive to set the default locale to, e.g., "en_US.UTF-8." Anyway, since r340144 (13-CURRENT — thanks yuripv@!), we have a "C.UTF-8" locale, and it is the default. Nov 30, 2018 at 2:07
  • 1
    @Conrad Meyer - super! - I did not know that. It will be great with more zane defaults. The world is slowly moving on from iso-8859-1 and Windows 1252 (And 850 and 865 and...) Dec 1, 2018 at 8:51

You must log in to answer this question.

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