Updated: This is not a file system problem.

I used to be able to enter:

$ echo kødpålæg

But now bash/zsh change this to:

bash$ echo kddddddddplg
zsh$ echo k<c3><b8>dp<c3><a5>l<c3><a6>g

I can run cat and enter 'kødpålæg' with no problem:

$ cat

This is both with this environment:

$ locale   

and in this:

$ locale 

csh does not change 'kødpålæg'.

How can I get the old behaviour back, so I can enter 'kødpålæg'?

Running any of these give the old behaviour:

LC_ALL=en_GB.utf-8 luit
LC_ALL=da_DK.utf-8 luit
LC_ALL=en_GB.iso88591 luit
LC_ALL=da_DK.iso88591 luit

but only for that single session.


$ od -An -vtx1


 c3 b8 0a

So it seems the input from Konsole to bash is UTF8.

$ konsole --version
QCoreApplication::arguments: Please instantiate the QApplication object first
Qt: 5.5.1
KDE Frameworks: 5.18.0
Konsole: 15.12.3

$ bash --version
GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ zsh --version
zsh 5.1.1 (x86_64-ubuntu-linux-gnu)

$ dpkg -l csh
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name              Version       Architecture  Description
ii  csh               20110502-2.1u amd64         Shell with C-like syntax
  • And with LANG=da_DK.UTF-8?
    – jasonwryan
    Jun 10, 2018 at 21:38
  • is your filesystem not supporting the characters? I can't repro with 4.4.12(1)-release and ext4.
    – Jeff Schaller
    Jun 10, 2018 at 22:49
  • Do you mean that when you run touch kødpålæg it creates a file called kdplg? How to you verify the name of the created file? Or that you pressing those ø, å keys seems to be ignored and the corresponding characters not inserted on the command line? Jun 11, 2018 at 6:33
  • What's the operating system? Terminal or terminal emulator? What version of bash/zsh? Jun 11, 2018 at 6:34

2 Answers 2


I'd say most likely your terminal is misconfigured and sends and displays characters in some single-byte character set, probably ISO8859-1 or ISO8859-15 given the sample characters you show instead of the locale's charset.

There is typically no ø, å, æ character in the C locale and the ISO8859-1(5) encoding of those characters (0xf8, 0xe5, 0xe6) don't form valid characters in UTF-8. Line editors like readline or zle need to decode those into characters as they need to know how many bytes make up a display column so they can do cursor positioning correctly.

Moreover, in the C locale which on most systems uses ASCII, since there are no character in ASCII with the 8th bit set, that 8th bit would be understood by bash as meaning Meta. 0xF8 would be understood as meaning Meta+x (0x78 (x) | 0x80), because that's what some terminals send upon Alt+x or Meta+x.

While M-x is not bound to anything by default in bash, ß would be understood as M-_ and insert the last word. You can turn that off with:

bind 'set convert-meta off'

Shells like csh are too ancient to even be aware that characters may be made of several bytes or take up anything but a single column width, so they don't bother.

To verify that theory, run:

od -An -vtx1

And enter those characters followed by ^D^D and see what encoding you see. If you see 0xf8 for ø, that means I'm right. If you see 0xc3 0xb8 instead, which is the UTF-8 encoding of ø that means I'm wrong.

Or change the locale to da_DK.iso88591 (check in locale -a for the exact name of the locale on your system) and see if that works better.

Now as to why your terminal may send the wrong encoding for those characters, maybe it was started in a locale where the charset was iso8859-1. Maybe it's configured to ignore the locale and use a specific charset (look for charset or encoding in its configuration). Or maybe you've sshed in from another system where the locale was using ISO8859-1(5) as its charset.

I can reproduce that behaviour if from a UTF-8 terminal, I run:

LC_ALL=en_GB.iso885915 luit

And from within luit change the locale to C or a UTF-8 one and enter non-ASCII characters.

  • bind 'set convert-meta off' works.
    – Ole Tange
    Jun 17, 2018 at 17:43

Your cat test indicates the terminal connection is 8-bit clean. So it seems a possible locale issue.

Please run locale -a to verify that your chosen locale "da_DK.utf8" exists; if it is not listed, and you are on a system that belongs to the Debian/Ubuntu family, you might have to uncomment it in /etc/locale.gen and then run locale-gen as root.

Also, some shell versions cannot switch locales dynamically, but keep using the locale setting that was originally inherited from their parent process. If this is the case, then running LC_CTYPE=da_DK.UTF-8 bash would restore the desired behavior, for the time of that particular session only. If that's true, then changing the system default locale to any supported UTF-8 locale and then rebooting might help: it would change the locale of the processes responsible for handling your login and starting your shell.

You must log in to answer this question.

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