Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

cabal-install doesn't work with National account name. #650

Open
bos opened this Issue · 11 comments

4 participants

@bos
Owner

(Imported from Trac #658, reported by @shelarcy on 2010-04-09)

If Windows user uses national account name, cabal update is fail.

See: http://www.sampou.org/cgi-bin/w3ml.cgi/haskell-jp/msg/545 (in Japanese)

I thought this problem is GHC 6.10.x and older's bug. So, I tested on Haskell Platform 2010.1.0.0 Windows installer RC3's cabal-install (version 0.8.1), and more recently version cabal-install 0.8.2. But this problem occur newer version (with my National account), too.

C:\Documents and Settings\崇裕>cabal update
Downloading the latest package list from hackage.haskell.org
cabal: invalid argument
And I tried to use cabal install command in package's directory. But cabal install is also fail.

C:\home\working\parsec-3.1.0>cabal install
cabal: C:\Documents and Settings\ユ\Application
Data\cabal\packages\hackage.haskell.org\00-index.tar: invalid argument
Above error message shows wrong path, but GHC 6.12.1's getTemporaryDirectory, getAppUserDataDirectory and getHomeDirectory show correct path.

Prelude System.Directory> getTemporaryDirectory
"C:\DOCUME~1\\23815\35029\LOCALS~1\Temp\"
Prelude System.Directory> getAppUserDataDirectory "cabal"
"C:\Documents and Settings\\23815\35029\Application Data\cabal"
Prelude System.Directory> getHomeDirectory
"C:\Documents and Settings\\23815\35029"
So, I think cabal's function passes ascii version's API (A) instead of wide charactor version's API (W) internally.

I don't know where this problem come from, cabal-install or Cabal or GHC's library. So, I report this bug on Hackage's Bug Tracker.

@bos
Owner

(Imported comment by @dcoutts on 2010-04-09)

Hmm, I expect the problem is that we store the repo cache directory in the cabal config file. Could you attach the config file please? cabal --help reports the location of the file.

@bos
Owner

(Imported comment by @shelarcy on 2010-04-10)

cabal config file

@bos
Owner

(Imported comment by @shelarcy on 2010-04-10)

Replying to @dcoutts:

Hmm, I expect the problem is that we store the repo cache directory in the cabal config file. Could you attach the config file please? cabal --help reports the location of the file.

cabal --help also shows wrong location.

C:\Documents and Settings\崇裕>cabal --help
(snip)
You can edit the cabal configuration file to set defaults:
C:\Documents and Settings\ユ\Application Data\cabal\config
Anyway, config file is in correct place (C:\Documents and Settings\崇裕\Application Data\cabal) . So, I attached config file.

@bos
Owner

(Imported comment by @dcoutts on 2010-04-10)

Replying to @shelarcy:

Replying to @dcoutts:
Hmm, I expect the problem is that we store the repo cache directory in the cabal config file. Could you attach the config file please? cabal --help reports the location of the file.

cabal --help also shows wrong location.
{{{
C:\Documents and Settings\崇裕>cabal --help
(snip)
You can edit the cabal configuration file to set defaults:
C:\Documents and Settings\ユ\Application Data\cabal\config
}}}


That is surprising. We're just using getAppUserDataDirectory "cabal". What do you get when you run

ghc -e 'System.Directory.getAppUserDataDirectory "cabal" >>= putStrLn'
I would expect that the console encoding is such that it looks correct.

Anyway, config file is in correct place (C:\Documents and Settings\崇裕\Application Data\cabal) . So, I attached config file.

Thanks. The cases where we write it out not using Haskell String syntax are clearly going wrong. We read/write the config file using readFile and writeFile. In ghc-6.12 these should use the current code page on windows. Do we know what code page this user has?

Perhaps we should always write the config file in utf8 on windows. It's less clear on Unix since file paths are not necessarily unicode on unix.

@bos
Owner

(Imported comment by @shelarcy on 2010-04-11)

Replying to @dcoutts:

That is surprising. We're just using getAppUserDataDirectory "cabal". What do you get when you run {{{ ghc -e 'System.Directory.getAppUserDataDirectory "cabal" >>= putStrLn' }}} I would expect that the console encoding is such that it looks correct.

putStrLn prints wrong string. Because IO library doesn't support double-byte encodings (Chinese/Japanese/Korean) on Windows platform, now.

C:\Documents and Settings\崇裕>ghc -e "System.Directory.getAppUserDataDirectory \"cabal\" >>= putStrLn"
C:\Documents and Settings\ユ\Application Data\cabal

Anyway, config file is in correct place (C:\Documents and Settings\崇裕\Application Data\cabal) . So, I attached config file.

Thanks. The cases where we write it out not using Haskell String syntax are clearly going wrong. We read/write the config file using readFile and writeFile. In ghc-6.12 these should use the current code page on windows. Do we know what code page this user has?


Okay, I understand what causes this problem.

Because of IO library doesn't support double-byte encodings on Windows platform, readFile and writeFile doesn't work correctly on double-byte encoding Windows environment.

@bos
Owner

(Imported comment by @shelarcy on 2010-04-11)

Replying to @dcoutts:

Perhaps we should always write the config file in utf8 on windows. It's less clear on Unix since file paths are not necessarily unicode on unix.

Anther solution is to use show and read, before readFile and writeFile.

C:\Documents and Settings\崇裕>ghc -e "System.Directory.getAppUserDataDirectory \"cabal\" >>= putStrLn . show"
"C:\\Documents and Settings\\\23815\35029\\Application Data\\cabal"
It think that config file's "install-dirs user" prefix field and "install-dirs global" prefix field are escaped by using show function.
install-dirs user
  -- prefix: "C:\\Documents and Settings\\\23815\35029\\Application Data\\cabal"
 (snip)
install-dirs global
  -- prefix: "C:\\Program Files\\Haskell"
@bos
Owner

(Imported comment by @kosmikus on 2010-04-11)

Is this still an issue with current versions of cabal-install?

@bos
Owner

(Imported comment by @shelarcy on 2012-03-05)

Replying to @kosmikus:

Is this still an issue with current versions of cabal-install?

Yes. This problem is not fixed in Haskell Platform's cabal-install 1.10.2.0, and GHC 7.4.1 with cabal-install HEAD.

C:\Users\崇裕>cabal --version
cabal-install version 0.10.2
using version 1.10.2.0 of the Cabal library
C:\Users\崇裕>cabal update
Config file path source is default config file.
Config file C:\Users\ユ\AppData\Roaming\cabal\config not found.
Writing default configuration to C:\Users\ユ\AppData\Roaming\cabal\config
Downloading the latest package list from hackage.haskell.org
C:\Users\崇裕>cabal install pqc
cabal:
C:\Users\ユ\AppData\Roaming\cabal\packages\hackage.haskell.org\00-index.tar:
invalid argument
C:\Users\崇裕>C:\TOOL\bin\new\cabal.exe --version
cabal-install version 0.13.3
using version 1.14.0 of the Cabal library
C:\Users\崇裕>C:\TOOL\bin\new\cabal.exe update
Config file path source is default config file.
Config file C:\Users\ユ\AppData\Roaming\cabal\config not found.
Writing default configuration to C:\Users\ユ\AppData\Roaming\cabal\config
Downloading the latest package list from hackage.haskell.org
C:\Users\崇裕>C:\TOOL\bin\new\cabal.exe install pqc
Warning: The package list for 'hackage.haskell.org' does not exist. Run 'cabal
update' to download it.
cabal.exe: There is no package named 'pqc'.
You may need to run 'cabal update' to get the latest list of available
packages.
@pawelp7

Hi, unfortunately I bumped on this issue too. I have application which works both on Windows and Linux. Personally I didn't noticed it in development (as I am mostly work on Linux), but during the deployment to users machines we encountered some bizarre problems (like "permission denied") which after thorough investigation turned out to be this bug. We would be extremely thankful if some of you guys could take a look into this bug.

I see that has been recently brought up to as #1583 -- is there any undergoing work towards solving this issue?

@wdanilo

Hello! We've got some big problems here related to this issue. Our product is distributed with ghc and cabal in a bundle and the amount of workarounds and dirty fixes needed to make it working on all windows machines is insane.
Is it possible to somehow just fix this bug in cabal ? I see, that a lot of people is facing this bug for over 2 years now :(

@23Skidoo
Collaborator

@wdanilo
I'll look into this.

@23Skidoo 23Skidoo self-assigned this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.