New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Templates fail when the environment variable LANG is not set to C.UTF-8. #1721
Comments
I looked into this a bit more. Hopefully this will be helpful. I found one instance of a non-ASCII character in a Mustache template, and many others in the off-by-default MathJax code:
I am pretty sure there is nothing we can do about the MathJax non-ASCII characters. There are many. They seem essential. But we could do away with the character in the Mustache template (we're using |
This surprises me as Ruby (2.0+) should be defaulting to UTF-8 anyway. This makes me think that, when Gollum reads non-application files from disk, they are not being properly transcoded and served as UTF-8. (See Ruby's documentation on Encoding#default_external and #default_internal if you're curious.) |
@benjaminwil - It seems if LANG is unset, Ruby 2.7 goes back to ASCII. Heres a quick demo: $ ruby --version
ruby 2.7.3p183 (2021-04-05 revision 6847ee089d) [x86_64-linux]
$ LANG= ruby -e 'puts "".encoding'
US-ASCII
$ |
I've looked into this a bit further. Gollum has magic Ruby keywords We can fix the issue by adding I think this is reasonable because of our optional MathJax dependency which uses a lot of non-ASCII characters. |
I will make a PR for this, by the way! |
An issue was reported (see #1721) where, in docker containers where the `LANG` was not being set, `Precious::App` would serve Mustache templates in an ASCII encoding. This caused templates to error out. In the past, this would have happened in environments where `LANG` was not set and the Gollum applciation configuration had enabled MathJax. Now, it happens even if MathJax is disabled because of a UTF-8 character I added to the mobile navigation menu. Basically, we should enforce a UTF-8 encoding from now on to avoid runtime errors related to ASCII encoding.
An issue was reported (see #1721) where, in docker containers where the `LANG` was not being set, `Precious::App` would serve Mustache templates in an ASCII encoding. This caused templates to error out. In the past, this would have happened in environments where `LANG` was not set and the Gollum applciation configuration had enabled MathJax. Now, it happens even if MathJax is disabled because of a UTF-8 character I added to the mobile navigation menu. Basically, we should enforce a UTF-8 encoding from now on to avoid runtime errors related to ASCII encoding.
I think we can close this thanks to @benjaminwil's #1731? |
Yes! Closing. |
Describe the bug
I use Gollum in a Kubernetes cluster, and the latest version threw an exception. The fix / work-around is to set
LANG=C.UTF-8
in the Pod environment. If I do not do this, Ruby defaults to ASCII and one of the templates Gollumpasses to Mustache contains a non-ASCII character.
I suggest documenting that the
LANG
must be set to UTF-8 or hunting down the template and making it ASCII compatible.To Reproduce
Steps to reproduce the behavior:
cmake
gcc
gcc-c++
patch
which
redhat-rpm-config
icu
libicu-devel
openssl-devel
zlib-devel
ruby-devel
rubygem-bcrypt
rubygem-rdoc
git
graphviz
nodejs
libffi-devel
rubygem-bundler
/usr/share/gems/gems/mustache-0.99.8/lib/mustache/context.rb:31:in 'gsub'
.Expected behavior
I expect Gollum to work when
LANG
is not set, or at least issue a clear warning message that it may fail.Screenshots
No screen shots. Reproduction instructions should demonstrate the problem. I'll include the exception stacktrace, though.
Environment Info
This is current Gollum (see recreation instructions).
This is running in IBM Cloud IKS (the managed Kubernetes offering). PODS do not have the
LANG
variable set when the pod'sENTRYPOINT
is executed, and so the Ruby VM sets itself to ASCII but a character in a template Gollum is using is non-ASCII.The text was updated successfully, but these errors were encountered: