Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

While answering a Unix-&-Linux question, I observed that Gedit and two other editors, Leafpad and Medit (I tested 12 editors altogether) exhibit the a certain bug. As it turns out, the bug is known to Canonical's launchpad as Bug #332321 search (and replace) takes ss as ß.

The bug's behaviour is that find ß will match both ß and ss... (not nice, especially if you do a replace-all).

I then noticed that the StackExchange software, in order to create the question's href link, had converted the question's title from How to bind “ß” to Meta-s? to how-to-bind-ss-to-meta-s.

So two completely unrelated environments are treating ß in a similar manner.. What is this strange attraction between ß and ss? ... and are there other such 'relationships'?

share|improve this question
up vote 5 down vote accepted

ß is actually a ligature of ss (in German). Anybody using a a table to convert Unicode or other extended alphabet characters to "safe" characters for things like URLs will likely convert it to ss.

Doing this for URLs is quite normal. For example I speak Turkish, where we have letters not found in English such as ö ü ı â ğ ç ş İ. These characters are not always safe to use in URLs, special form fields, etc. In their place we substitute similar characters such as o u i a g c s I. Usually this is done by visual similarity rather than sound, but the case of ß the audible similarity to ss makes it a common conversion.

This constitutes a net-loss of data, but as a safe representation of a URL or other special field it works, then on the site itself you can use the real characters.

Why gedit would be doing this conversion is beyond me. It's a bug.

share|improve this answer
Again! I've got to learn to read faster :/ – rozcietrzewiacz Aug 2 '11 at 17:52
@Caleb: Aha! I see. It certainly makes sense with it being a ligature, thanks... (so, the gedit bug may have other clashing codepoints)... – Peter.O Aug 2 '11 at 18:02

Case normalization. <goes to check with Gedit> Yup.

When you make a case-insensitive search, GEdit (and I presume the others) normalize the case, and this causes a number of character equivalences to collapse. For example, ß and ss both uppercase to SS. Composite characters such as é and é (the first is U+00E9 LATIN SMALL LETTER E WITH ACUTE, the second is U+0301 COMBINING ACUTE ACCENT followed by U+0065 LATIN SMALL LETTER E) are also considered equivalent there.

If you make a case-sensitive search, these character sequences are all considered different.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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