The Grand JetBrains Locale Kerfuffle

I assume JetBrains has a legitimate reason for setting the LC_CTYPE environment variable to “UTF-8” in the JetBrains 2025.x terminal. Whatever that reason is, it makes remote SSH servers very upset:

ssh remote-debian-server.pizza
Linux ned 6.12.48+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.48-1 (2025-09-20) x86_64
...
Last login: Wed Dec 17 10:53:09 2025 from 10.0.73.10
-bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8): No such file or directory
-bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8): No such file or directory
-bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8): No such file or directory
-bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8): No such file or directory
-bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8): No such file or directory

The ssh binary from OpenSSH shipped with macOS dutifully reads /etc/ssh/sshconfig.d/100-macos.conf and does what it is instructed, shipping all environment variables matching LC_* to the remote host.

The issue is that my Debian servers do not appreciate the goofball locale string of “UTF-8” and complain loudly. The correct string would have been "en_US.UTF-8" or another appropriate value.

I spent more time than warranted trying to find a configuration setting to prevent JetBrains from clobbering my environment. In the end, I just needed to get on with my day. I added the following to my ~/.bash_profile:

if [[ "$" == JetBrains* ]]; then
  unset LC_CTYPE
fi

Cloning AWS ECR Repositories

While migrating from one AWS Account to another, I needed to clone all the images from the ECR repositories. A utility named Skopeo performs this task very well. There’s a subtle catch with repositories that have / characters in the name, but that’s dealt with using some Bash trickery.

The network speed when performing the clone is underwhelming — about 4 Mb/sec on average. If this was a bigger job, I probably would have started the execution from a compute node within the region.

1Password and Vivaldi on Debian Bookworm

There’s an extra step to required to enable the browser extension to communicate with the desktop application. I found a few old post on the 1Password Support Bulletin Board where some instructions have been pasted. It’s still necessary today in Feb 2025 to create a file at /etc/1password/custom_allowed_browsers with the executable name of the browser to trust. In this case, vivaldi-bin. The file mode of 0644 is fine. I don’t know why the suggestion was made to make the configuration file executable.