win98, ctrl-c & System.system (was: Updated 6.4 Windows installer RC)

Simon Marlow simonmar at microsoft.com
Wed Mar 23 05:54:27 EST 2005


On 22 March 2005 21:58, Claus Reinke wrote:

>> Yet another 6.4 installer, this time fixing issues regarding GHC
>> use on Win9x / NT4 installations:
>> http://www.haskell.org/ghc/dist/stable/dist/ghc-6-4-bld2.msi
>> Unless some _really bad_ platform-specific bugs are reported against
>> this one soon, that's the final 6.4 installer.
> 
> sorry to be complaining about issues with a pre-OS that, by all
> rights, should be gone and forgotten, but I thought I'd at least
> report such things as I find.
> 
> the new snapshot installs and runs fine on win98se, but someone
> tries to be too clever about catching <ctrl>-C, it seems. not that
> I particularly liked the old behaviour (dropping out of a ghci
> session when interrupting a loop), but this is no improvement.
> 
> in the appended log, after ghci starts up, I just repeatedly type
> <ctrl>-c, and though the bash prompt appears, ghci isn't
> quite gone, and there appears to be some competition about
> further inputs.. if I'm lucky, I get a complete command through
> to bash, then type <ctrl>-c to be back in ghci-land for a moment,
> with similar problems to complete commands, but if I manage to
> get an unclobbered :q<ret> through, things seem to return to
> normal, at bash-level.

Yes, it's pretty bad.  You can hang a terminal like this, so you have to
kill GHC with the task manager to get it back.  Sigh.

Please file a(nother) bug, we'll try to improve things for 6.4.1.

> either keeping in ghci-level or dropping to bash-level would
> be better than this mixture. I notice that this new catching of
> <ctrl>-c seems to work as intended if I start ghci from the
> start-menu, ie without cygwin bash, but that is very
> unconfigurable/uncomfortable on win98 (tiny window-size
> without scrolling, in which I can't even see the complete
> output of ":?".

Strange - command prompt windows should be nice and large and
scrollable, mine are at least.  Cut-and-paste support is terrible,
though.  Generally I use XTerm under Cygin's X server to get a decent
command line experience on a Windows box.

> while I was at win98-specific issues, I remembered the old
> "System.system always returns ExitSuccess on ghc/win98"
> (somewhat of a nuisance when you're trying to run a suite
> of tests from within Haskell that involve external commands).
> so I tried to check that, but:
> 
> Prelude> System.system "ls" >>= print
> *** Exception: C:\WINDOWS\SYSTEM\CMD.EXE: runCommand: does not exist
> (No such fi le or directory)
> Prelude> System.Cmd.rawSystem "ls" [] >>= print
> _viminfo  getname.pl  index.html
> ExitSuccess
> Prelude> System.system "false" >>= print
> *** Exception: C:\WINDOWS\SYSTEM\CMD.EXE: runCommand: does not exist
> (No such fi le or directory)
> Prelude> System.Cmd.rawSystem "false" [] >>= print
> ExitFailure 1

Works for me!  Remember that System.system is executing CMD.EXE, not
Cygwin bash, so it'll probably have a different PATH and might not be
able to find your Cygwin binaries.  Both System.system "dir", and
System.system "c:/cygwin/bin/ls" work for me.

> so, in brief:
> - catching <ctrl>-c from ghci running under bash leads to
>     trouble.
> - System.system does not appear to work anymore? it
>     can't seem to find any command.
> - System.Cmd.rawSystem does seem to solve that old
>     ExitCode problem, but why is it better at finding
>     commands than System.system? shouldn't it be
>     the other way round?

Perhaps rawSystem is using the current PATH setting, which it inherited
from the bash shell, whereas System.system is starting a new CMD.EXE
which resets the PATH?  Try System.system "set PATH".

Cheers,
	Simon



More information about the Glasgow-haskell-bugs mailing list