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-8in 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
fishand 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
--loginflag to your shell (alacrittydoing this by default). This is how your shell section inalacritty.ymlshould look like.Edit:
By defaultmeans 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 programin 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.