Skip to content
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

hGetContent says invalid byte sequence on Windows, non-English locale #157

Open
ice1000 opened this issue Oct 30, 2019 · 4 comments
Open

Comments

@ice1000
Copy link

ice1000 commented Oct 30, 2019

Before doing this readFile:

https://github.com/simonmar/happy/blob/27596ff0ce0171d485bf96d38943ffc760923c90/src/Main.lhs#L72-L74

we may do hSetEncoding h IO.utf8 before.

See agda/agda#4161 (comment)

@andreasabel
Copy link
Member

You could submit a PR, it is probably easier for you to test the change as you have the right context (Windows, non-English locale).

@lehins
Copy link

lehins commented Feb 12, 2020

This applies to non-Windows systems as well. If your locale is not set or set to something like LANG=ascii, reading files with unicode in them will result in this error. In fact we received this error on Linux machine as well with this happy file: https://github.com/erikd/language-javascript/blob/eef1887d430c18b108ff723479c3f1ef50c0e9b2/src/Language/JavaScript/Parser/Grammar7.y

I fixed an issue exactly like this one with hpc: https://gitlab.haskell.org/ghc/ghc/issues/17073

Same fix could be applied here. Haskell source files are always assumed to be encoded in utf-8, same principal could be applied to happy .y files.

@hdgarrood
Copy link

This has caused problems for people trying to build the purescript compiler from source too: eg purescript/purescript#3813, erikd/language-javascript#86. I think having happy always assume that .y files are UTF-8 encoded would indeed be a good option.

andreasabel added a commit to agda/agda that referenced this issue Jul 17, 2021
This is a workaround for upstream issue

    haskell/happy#157

By sticking to ASCII, we avoid locale issues.
andreasabel added a commit to agda/agda that referenced this issue Jul 17, 2021
This is a workaround for upstream issue

    haskell/happy#157

By sticking to ASCII, we avoid locale issues.
andreasabel added a commit to agda/agda that referenced this issue Nov 17, 2021
This is a workaround for upstream issue

    haskell/happy#157

By sticking to ASCII, we avoid locale issues.
@thatwist
Copy link

thatwist commented Mar 7, 2023

struggled with this.. this combo worked for me

echo "LC_CTYPE=\"en_US.UTF-8\"" | sudo tee -a /etc/default/locale
echo "LC_ALL=\"en_US.UTF-8\"" | sudo tee -a /etc/default/locale
echo "LANG=\"en_US.UTF-8\"" | sudo tee -a /etc/default/locale
echo "LC_ALL=en_US.UTF-8" | sudo tee -a /etc/environment
echo "en_US.UTF-8 UTF-8" | sudo tee -a /etc/locale.gen
echo "LANG=en_US.UTF-8" | sudo tee -a /etc/locale.conf
sudo locale-gen en_US.UTF-8

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants