Sorry, it's not me who invented it. There are many tools (from Unix origin) that use HOME in Windows if defined. In fact, let me think... oh, yeah, I remember, GHCi itself used it until this very same morning... :)
yes, but ghc/ghci switched from unix-emulated to windows-native long ago - since then, they've tried to behave more like other windows programs, with no built-in knowledge of unixisms. now, imagine the surprise when, in your %HOME%/.ghci, you do home <- System.Directory.getHomeDirectory System.Directory.getDirectoryContents home and the script ghci claims to be executing isn't even there!-) or imagine switching between console (no HOME) and bash (inherited HOME) ghci: now you see .ghci, now you don't..
No. I don't "take care" of the Windows-provided home dir, because it is mostly used *automatically* by programs that write their setting files to it. It is rare indeed the Windows program that requires the user to go to %HOMEDRIVE%%HOMEPATH% and edit a file there.
it would be useful if ghci could read/write its current settings (perhaps split into a .cabal file with settings and a .ghci file with scripts/definitions). but you wouldn't want it to ovewrite your old .ghci, and some of us would still like to know where it ends up so that we can check and edit it manually, or copy it elsewhere;-)
Thanks, I'll use that. However, I still think that breaking back-compatibility is Not a Good Idea.
in general, i would agree. perhaps my fault for filing that ticket in absolutes, which led to a fix replacing, rather than augmenting, the old, erroneous behaviour. but a HOME-overrides-HOMEPATH approach, while backwards-compatible, suffers from the same inconsistency issues as the old please-define-HOME-yourself approach (even worse: you might get different versions of .ghci). so, one would have to implement the overriding approach consistently (including getHomeDirectory), and issue warnings and documentation to make users aware of any such overriding taking place (and should it be optional, to avoid deviating from the platform standard?).. as a short-term deprecation workaround for ghc-6.8.x, that makes some sense, but in the long-term? claus