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
- Fix startup locale on macOS Fixes #2800. Fixes #2566. — committed to alacritty/alacritty by casperstorm 4 years ago
- Fix startup locale on macOS Fixes #2800. Fixes #2566. — committed to alacritty/alacritty by casperstorm 4 years ago
- Fix startup locale on macOS Fixes #2800. Fixes #2566. — committed to alacritty/alacritty by casperstorm 4 years ago
- Fix startup locale on macOS Fixes #2800. Fixes #2566. — committed to boxofrox/alacritty by casperstorm 4 years ago
There are some differences but I don’t think they’re related, the one that works has the following extras:
I believe those are things inherited by iterm
Alright! after adding
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 beforeI 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
Update: @chrisduerr was faster then me :- ).
No, I still have LC_CTYPE in my alacritty.yml:
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.
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 inalacritty.yml
should look like.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.ymlI’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.