Further information: The source of the readKeyFixup function which is causing this bug can be read here:
https://github.com/fsharp/fsharp/blob/de709b30d9b5fdb620ff4e1d439122cdac11ffa1/src/fsharp/fsi/console.fs#L24-L42 In addition to using the NO_SERVERCODEPAGES compilation flag (which I believe to be the best approach for the Debian package, for reasons explained below), another possible approach would be to add a patch to the Debian package that would change line 20 of console.fs from: let fixupRequired = not FSharpEnvironment.IsRunningOnNetFx45OrAbove to: let fixupRequired = false (That's line 20 of console.fs in the current master branch of the upstream Git repo, which I linked to above. In the code that currently exists in the Debian package repo, it's line 18, not line 20, of console.fs). The reason for making this change in a patch rather than submitting it upstream is because upstream would need to care about producing Windows builds of fsi.exe as well, whereas the Debian package of fsharp will never be used to build anything but Linux builds. Now, why do I believe that using the NO_SERVERCODEPAGES compilation flag is the best long-term approach? Because that disables precisely three bits of code: 1) The readKeyFixup function, which is trying to fix a Windows-only bug and thereby *introducing* a bug on Linux; 2) The SetServerCodePages function in fsi.fs (see https://github.com/fsharp/fsharp/blob/de709b30d9b5fdb620ff4e1d439122cdac11ffa1/src/fsharp/fsi/fsi.fs#L629-L657 for source code), which handles two command-line options to set *numeric* code pages. Those are a Windows-only feature (I'd argue that they're a misfeature, but I can't change Microsoft's decisions), and those options *should* be disabled on Linux. Disabling the code that handles these options won't cause an error if someone passes those options on the command line (say, because they're writing a cross-platform script); it will simply cause fsi.exe to silently ignore those options. 3) A small bit of code later in fsi.fs (https://github.com/fsharp/fsharp/blob/de709b30d9b5fdb620ff4e1d439122cdac11ffa1/src/fsharp/fsi/fsi.fs#L2293) that calls SetServerCodePages. That's it. Using the NO_SERVERCODEPAGES compile flag will disable precisely those three bits of code, and nothing else. Furthermore, using that compile flag will not cause any problems even if someone has written a cross-platform script that uses the undocumented --fsi-server-input-codepage and --fsi-server-output-codepage options that this compile flag disables, because when compiled with NO_SERVERCODEPAGES, fsi.exe still accepts those command-line options (they just do nothing). So there are two options to solve this bug: 1) (The better approach). Pull in a more recent tag from the upstream Git repo (https://github.com/fsharp/fsharp). The NO_SERVERCODEPAGES was added in between tags 4.0.1.1 (tagged on 2015-12-05) and 4.0.1.2 (tagged on 2016-07-16). The most recent upstream tag is 4.0.1.20 (tagged on 2016-11-14), but any version from 4.0.1.2 onwards will include the NO_SERVERCODEPAGES compilation flag and will allow you to fix this bug. This is definitely the right choice for the unstable distribution, and probably for testing as well. This will, however, bring in other upstream code changes at the same time, so for any distributions that are in stable-release mode and don't want to bring in new upstream code, it might be best to go with the second, more conservative approach. 2) (The more conservative approach). For any distro that wants to stick with fsharp 4.0.0.4 and make only minor changes, a single-line patch to console.fs (to change the "fixupRequired" variable to be unconditionally false, as I described above) is the most conservative approach. This will fix this bug on all Debian releases, without needing to bring in any extra upstream code that may not be desired. I'll prepare a patch that takes the #2 approach, and I suggest taking the #1 approach for the version of the fsharp package that's uploaded to unstable. (Which will need to be bumped again pretty soon anyway, once F# 4.1 is released). Sincerely, Robin Munn
