alacritty: Inconsistent locale when running from command line vs from dock

Which operating system does the issue occur on? Macos, Alacritty version 0.3.3, Swedish keyboard

I installed Alacritty via homebrew

If I start alacritty via the Icon in the dock/ Applications folder then the åäö characters doesn’t work, å and ä does nothing and ö prints (arg: 6)

however, if I open Alacritty by running /Applications/Alacritty.app/Contents/MacOS/alacritty in iTerm2, then those characters works just fine

is env/dotfiles loaded differently or something?

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 32 (16 by maintainers)

Commits related to this issue

Most upvoted comments

There are some differences but I don’t think they’re related, the one that works has the following extras:

TERM_PROGRAM=iTerm.app
TERM_PROGRAM_VERSION=3.1.6
TERM_SESSION_ID=w0t2p0:FEBB2B01-AD10-4CB7-9A16-E9661B15D728
ITERM_PROFILE=Default
COLORFGBG=7;0
ITERM_SESSION_ID=w0t2p0:FEBB2B01-AD10-4CB7-9A16-E9661B15D728

I believe those are things inherited by iterm

Alright! after adding

env:
  LC_ALL: "sv_SE.UTF-8"

to my alacritty yml it now works properly! 💯 Thank you so much for you help and patience!

setting it to "C" has the same faulty behaviour as before

I am fine with that solution, but why could it be that I need to set it in my yml and not just in my bash profile?

You can try this as a last resort

shell:
  program: /usr/local/bin/fish
  args:
    - --login
    - -c
    - /usr/local/bin/tmux

Update: @chrisduerr was faster then me :- ).

No, I still have LC_CTYPE in my alacritty.yml:

env:
  # https://github.com/jwilm/alacritty/issues/2566
  LC_CTYPE: en_US.UTF-8

I have the same issue (see https://github.com/jwilm/alacritty/issues/2837). After reading this I noticed that my setup is actually a bit comparable. My macOS is set to german, but with an US keyboard layout. For now I also resorted to setting LC_CTYPE: en_US.UTF-8 in alacritty.yml.

I do have german and english in my preferred languages in “Sprache & Region” (Language & Locale?) in system settings, but I didn’t set this up manually. Maybe macOS did it when I added the US keyboard. A coworkers german MacBook with no US keyboard only has german in that list, but his Terminal.app also shows de_DE.UTF-8 in all values except LC_ALL.

grafik

Just fyi, another thing you can try is to just set the shell in Alacritty to fish and then set the arguments to [--login, -c, tmux]. That should first spawn a login shell and then execute tmux inside of it.

That should definitely do the job if login shells work for you. But it seems like this is a separate issue, so it’s probably best not to clutter this thread too much with it. If you need more help, feel free to open a separate issue.

@tofagerl You should pass --login flag to your shell (alacritty doing this by default). This is how your shell section in alacritty.yml should look like.

shell:
  program: /usr/local/bin/tmux
  args:
    - --login

Edit: By default means when you haven’t set your shell explicetly in a config file.

I’m seeing the same problem with slight differences. I use a font with extra powerline characters, so that’s how I noticed it, but can’t see Scandinavian characters either. (I’m Norwegian) However, I have the exact same environment settings in both iTerm2 and Alacritty, and when launching Alacritty from Alfred and from iTerm2. They’re en_US.UTF-8 as they should be. I have this new variable though: when I launch my shell with Tmux configured to automatically launch, it fails to show the extended characters, but when I comment that out, everything is fine. I can then manually launch tmux, and everything is fine. This also happens when I set tmux as my shell program in alacritty.yml

I’ve reported the issue upstream at https://github.com/rust-windowing/winit/issues/943, maybe they have an idea at what could be going on.