Encoding issues due to missing locale settings

[marcelotto]

The shell environment (at least with Zsh under MacOS) does not define the LC_CTYPE environment variable which is usually set automatically by the system. Also, the locale LC_CTYPE returns a very basic US-ASCII. This is causing, for example, encoding issues when copying a text with characters outside of this character set to the clipboard with pbcopy.

The problem can be seen by creating a shell command echo $LC_CTYPE ; locale LC_CTYPE which produces the following output on my system:

US-ASCII

In a normal shell environment, this command produces this output on my system:

UTF-8
UTF-8

[Taitava]

Hi! Thank you for your message! 🙂

This is valuable information to me, as it makes me learn about how the default shells of this plugin behave. I'm not very familiar with Zsh, and I don't have macOS, so I can't really do much testing.

However, I guess that this happens because when using the normal shells built into the SC plugin, Node.js's child_process does not use a -l (login) switch when it invokes a shell. If this switch was used, Zsh would process additional configuration files before executing your command. As those configuration files are not processed, I supect it causes the LC_CTYPE environment variable not to be defined.

Perhaps you could try to solve this problem by creating a custom shell configuration for Zsh that includes the -l argument:

• General instructions on configuring custom shells
• Shell name: For example Custom Zsh
• Executable binary file path: /bin/zsh
• Shell arguments:

  -l
  -c {{!shell_command_content}}
  

• Host operating system and Shell's operating system: macOS for both.
• Special characters escaping: Unix shell style with \ as escape character
• Path translator: Not needed, so please leave empty.
• Wrapper for shell command: Not needed, too.
• After creating the custom shell configuration, please remember to make your shell commands use the configuration.

Please let me know if this solved tthe problem or not, or if you have any other questions. 👍

[marcelotto]

Sorry for the late reply. I was offline for the past few days due to sickness.

Thanks for pointing out a potential workaround. Unfortunately, this isn't possible in my use case, which is the Magma project that creates Obsidian vaults for its users and offers additional commands on top of those vaults (that are triggered with this plugin). In this scenario, however, I actually can not assume a particular shell that users might have.

The workaround I'm currently using is to set the LC_CTYPE in a shell wrapper script I'm already using to perform the Magma command calls in a portable manner (marcelotto/magma@c129f4f).

I just wanted to point out this problem as I can imagine it might affect more users of this plugin.

[Taitava]

Oh, that's true, in that case you cannot assume users have a certain shell.

Maybe I should think about changing the builtin shells so that they would use the -l (login) switch on Linux and macOS, so that startup scripts get executed. The current state of not running the startup scripts has already caused a lot of problems related to missing directories in $PATH, and now this encoding problem appeared.