[ ghc-Bugs-1175454 ] System.system fails on windows98se, also disables ghci's :!
Bugs item #1175454, was opened at 2005-04-02 18:03 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1175454group_id=8032 Category: libraries/base Group: 6.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: System.system fails on windows98se, also disables ghci's :! Initial Comment: as reported and discussed in the thread win98, ctrl-c System.system (was: Updated 6.4 Windows installer RC) on glasgow-haskell-bugs. first messages in thread: http://www.haskell.org//pipermail/glasgow-haskell- bugs/2005-March/004856.html http://www.haskell.org//pipermail/glasgow-haskell- bugs/2005-March/004857.html Sigbjorn suggested a fix, getting the command interpreter to use from the environment instead of hardcoding it: http://www.haskell.org//pipermail/glasgow-haskell- bugs/2005-March/004862.html note that on my windows98se system, there is no command.exe, only command.com: $ echo $COMSPEC C:\WINDOWS\COMMAND.COM which does support the /c switch. Btw, I can't find a way to pass this switch through System.Cmd.rawSystem - can anyone enlighten me on how to do this? [EMAIL PROTECTED] -- Comment By: Simon Marlow (simonmar) Date: 2005-04-05 08:41 Message: Logged In: YES user_id=48280 I've fixed this, 6.4.1 should be better (though I can't test it, so I'd appreciate it if you would test a pre-release when the time comes). I can use rawSystem to invoke cmd.exe /c here. eg. this works: rawSystem c:\windows\system32\cmd.exe [/c, dir] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1175454group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [ ghc-Bugs-1175454 ] System.system fails on windows98se, also disables ghci's :!
[don't want to reopen the ticket, don't like the mini comment field on sf, and I no longer trust the handling of \ on sf (see below); so I'll reply here] I've fixed this, 6.4.1 should be better (though I can't test it, so I'd appreciate it if you would test a pre-release when the time comes). Thanks. COMMAND.COM may still exist on newer windows versions, which would allow you to do some testing by setting %COMSPEC%? (ms/intel try to be backwards compatible with their first abacus;) But I'm looking forward to a first working windows release candidate!-) when? and what about the ctrl-c horrors? I can use rawSystem to invoke cmd.exe /c here. eg. this works: rawSystem c:\windows\system32\cmd.exe [/c, dir] hey, who are you trying to fool now?-) the above isn't even legal Haskell! [there are double backslashes in the sourceforge version, but not in the ghc-bugs version? I keep staring at your email, but I still can't believe this!] Appended at the end is a recap of what happens on my windows98se system. Note that with separate option, there's an error message and no listing, and with option/parameter as a single element, the dir at least gets executed, but the error message is still there. If that works for you, without errors, it almost sounds as if rawSystem is cmd.exe-specific, instead of command-interpreter-independent, as was the idea? Or at least it doesn't cooperate with COMMAND.COM (perhaps the syscall you use works differently on win98?..). Btw, I can produce the same effects within COMMAND.COM if I put parts of the command line in quotes (don't know whether that is a misleading coincidence or a useful hint): D:\cygwin\home\unknowncommand.com /c cd D:\cygwin\home\unknown D:\cygwin\home\unknowncommand.com /c cd Angegebenes COMMAND-Verzeichnis ist falsch Befehl oder Dateiname nicht gefunden. D:\cygwin\home\unknowncommand.com /c cd Angegebenes COMMAND-Verzeichnis ist falsch D:\cygwin\home\unknown D:\cygwin\home\unknown Cheers, Claus $ ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.4, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base-1.0 ... linking ... done. Prelude Prelude System.Cmd.rawSystem c:\windows\command.com [/c,dir] interactive:1:26: lexical error in string/character literal Prelude System.Cmd.rawSystem c:\\windows\\command.com [/c,dir] Angegebenes COMMAND-Verzeichnis ist falsch Befehl oder Dateiname nicht gefunden. Prelude System.Cmd.rawSystem c:\\windows\\command.com [/c dir] Angegebenes COMMAND-Verzeichnis ist falsch Datenträger in Laufwerk D: hat keine Bezeichnung Seriennummer des Datenträgers: 417D-08FC Verzeichnis von D:\cygwin\home\unknown . DIR06.04.02 21:34 . .. DIR06.04.02 21:34 .. BASHRC~1 300 22.03.05 15:06 .bashrc BASH_H~1 9.605 05.04.05 2:42 .bash_history VIMINF~110.659 02.04.05 19:40 .viminfo SSH~1 DIR11.06.02 0:12 .ssh CVSPAS~145 22.06.02 20:51 .cvspass INDEX~1 HTM52.045 10.06.03 23:27 index.html BASHRC~2 302 19.03.05 13:14 .bashrc~ GETNAME PL140 24.09.03 14:27 getname.pl EMACS~1 D DIR31.10.03 15:37 .emacs.d _VIMINFO 8.430 29.05.04 16:26 _viminfo FONTS~1 CAC 0 04.07.04 14:04 .fonts.cache-1 9 Datei(en)81.526 Bytes 4 Verzeichnis(se) 165.695.488 Bytes frei Prelude Prelude System.Cmd.rawSystem c:\\windows\\command.com [/c echo %PATH%] Angegebenes COMMAND-Verzeichnis ist falsch ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: [ ghc-Bugs-1175454 ] System.system fails on windows98se, also disables ghci's :!
Hi Claus, I can't fathom what's going on with rawSystem on your box. Perhaps the Win98 version of command.com has different quoting semantics, which don't match what rawSystem is assuming. I don't imagine I'll be able to make much progress on that, but I'll be happy to incorporate a fix if you can find one. We'll definitely do something about the ctrl-C issues before 6.4.1. No firm release plans yet, but we'll keep you posted. Cheers, Simon On 05 April 2005 13:27, Claus Reinke wrote: [don't want to reopen the ticket, don't like the mini comment field on sf, and I no longer trust the handling of \ on sf (see below); so I'll reply here] I've fixed this, 6.4.1 should be better (though I can't test it, so I'd appreciate it if you would test a pre-release when the time comes). Thanks. COMMAND.COM may still exist on newer windows versions, which would allow you to do some testing by setting %COMSPEC%? (ms/intel try to be backwards compatible with their first abacus;) But I'm looking forward to a first working windows release candidate!-) when? and what about the ctrl-c horrors? I can use rawSystem to invoke cmd.exe /c here. eg. this works: rawSystem c:\windows\system32\cmd.exe [/c, dir] hey, who are you trying to fool now?-) the above isn't even legal Haskell! [there are double backslashes in the sourceforge version, but not in the ghc-bugs version? I keep staring at your email, but I still can't believe this!] Appended at the end is a recap of what happens on my windows98se system. Note that with separate option, there's an error message and no listing, and with option/parameter as a single element, the dir at least gets executed, but the error message is still there. If that works for you, without errors, it almost sounds as if rawSystem is cmd.exe-specific, instead of command-interpreter-independent, as was the idea? Or at least it doesn't cooperate with COMMAND.COM (perhaps the syscall you use works differently on win98?..). Btw, I can produce the same effects within COMMAND.COM if I put parts of the command line in quotes (don't know whether that is a misleading coincidence or a useful hint): D:\cygwin\home\unknowncommand.com /c cd D:\cygwin\home\unknown D:\cygwin\home\unknowncommand.com /c cd Angegebenes COMMAND-Verzeichnis ist falsch Befehl oder Dateiname nicht gefunden. D:\cygwin\home\unknowncommand.com /c cd Angegebenes COMMAND-Verzeichnis ist falsch D:\cygwin\home\unknown D:\cygwin\home\unknown Cheers, Claus $ ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.4, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base-1.0 ... linking ... done. Prelude Prelude System.Cmd.rawSystem c:\windows\command.com [/c,dir] interactive:1:26: lexical error in string/character literal Prelude System.Cmd.rawSystem c:\\windows\\command.com [/c,dir] Angegebenes COMMAND-Verzeichnis ist falsch Befehl oder Dateiname nicht gefunden. Prelude System.Cmd.rawSystem c:\\windows\\command.com [/c dir] Angegebenes COMMAND-Verzeichnis ist falsch Datenträger in Laufwerk D: hat keine Bezeichnung Seriennummer des Datenträgers: 417D-08FC Verzeichnis von D:\cygwin\home\unknown . DIR06.04.02 21:34 . .. DIR06.04.02 21:34 .. BASHRC~1 300 22.03.05 15:06 .bashrc BASH_H~1 9.605 05.04.05 2:42 .bash_history VIMINF~110.659 02.04.05 19:40 .viminfo SSH~1 DIR11.06.02 0:12 .ssh CVSPAS~145 22.06.02 20:51 .cvspass INDEX~1 HTM52.045 10.06.03 23:27 index.html BASHRC~2 302 19.03.05 13:14 .bashrc~ GETNAME PL140 24.09.03 14:27 getname.pl EMACS~1 D DIR31.10.03 15:37 .emacs.d _VIMINFO 8.430 29.05.04 16:26 _viminfo FONTS~1 CAC 0 04.07.04 14:04 .fonts.cache-1 9 Datei(en)81.526 Bytes 4 Verzeichnis(se) 165.695.488 Bytes frei Prelude Prelude System.Cmd.rawSystem c:\\windows\\command.com [/c echo %PATH%] Angegebenes COMMAND-Verzeichnis ist falsch ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [ ghc-Bugs-1175454 ] System.system fails on windows98se, also disables ghci's :!
I can't fathom what's going on with rawSystem on your box. Perhaps the Win98 version of command.com has different quoting semantics, which don't match what rawSystem is assuming. I don't imagine I'll be able to make much progress on that, but I'll be happy to incorporate a fix if you can find one. Let me see if I get the call-chain correct (System.-prefix omitted): Cmd.rawSystem - Process.runProcess - Process.Internals.runProcessWin32 Cmd.system - Process.runCommand - Process.Internals.commandToProcess + Process.Internals.runProcessWin32 The first thing I notice is that commandToProcess doesn't do much (well, now it tries to find a command interpreter, but it does no translation) - both variants go through runProcessWin32, which calls Process.Internals.translate! Is that intended?? It looks like a bug to attempt counter-translation for Cmd.system? As far as I can see, that means that both system and rawSystem will create command-lines rich with quotes, and as I mentioned, command.com will choke on those. Prelude :m System.Process.Internals Prelude System.Process.Internals translate comspec \C:\\WINDOWS\\COMMAND.COM\ Prelude System.Process.Internals translate /c \/c\ Prelude System.Process.Internals translate cd \cd\ Prelude System.Process.Internals translate /c cd \/c cd\ Prelude System.Process.Internals :m -System.Process.Internals Here is what happens with rawSystem: Prelude let rs = System.Cmd.rawSystem Prelude comspec - System.Environment.getEnv COMSPEC Prelude comspec C:\\WINDOWS\\COMMAND.COM Prelude rs comspec [/c,cd] Angegebenes COMMAND-Verzeichnis ist falsch Befehl oder Dateiname nicht gefunden. Prelude rs comspec [/c cd] Angegebenes COMMAND-Verzeichnis ist falsch D:\cygwin\home\unknown Prelude And here are what I think are the corresponding calls in a command.com shell - at least they evoke the same reactions: C:\Windowscommand.com /c c:\windows\command.com /c cd Angegebenes COMMAND-Verzeichnis ist falsch Befehl oder Dateiname nicht gefunden. C:\Windowscommand.com /c c:\windows\command.com /c cd Angegebenes COMMAND-Verzeichnis ist falsch C:\Windows If this is correct, any fix would at least involve omitting the quotes around the parameters if the command-line invokes command.com. As an experiment, I created my own version of the rawSystem-chain, replacing the call to translate for the args in runProcessWin32 with a call to id, and that seems to be sufficient to solve this problem: Compiling Main ( NewCmd.hs, interpreted ) Ok, modules loaded: Main. *Main rawSystem command.com [/c,cd] D:\cygwin\home\unknown *Main comspec - System.Environment.getEnv COMSPEC *Main rawSystem comspec [/c,cd] D:\cygwin\home\unknown *Main System.Cmd.rawSystem comspec [/c,cd] Angegebenes COMMAND-Verzeichnis ist falsch Befehl oder Dateiname nicht gefunden. *Main rawSystem comspec [/c cd] D:\cygwin\home\unknown *Main rawSystem comspec [/c,echo %PATH%] c:\Programme\Hugs98;c:\Programme\GreenCard;c:\ghc\ghc-6.4\bin;D:\cygwin\usr\X11r 6\bin;c:\texmf\miktex\bin;d:\Software\jdk1.2.1\bin;D:\cygwin\usr\local\bin;D:\cy gwin\bin;D:\cygwin\bin;c:\TEXMF\MIKTEX\BIN;c:\GHC\GHC-6.4\BIN;c:\WINDOWS;c:\WIND OWS;c:\WINDOWS\COMMAND;c:\ADABAS\BIN;c:\PROGRAMME\ERL5.1\BIN;c:\PROGRA~1\ATT\GRA PHVIZ\BIN;c:\ADABAS\PGM;c:\PROGRAMME\ERL5.1\BIN;D:\cygwin\usr\X11R6\bin *Main System.Cmd.rawSystem comspec [/c,echo %PATH%] Angegebenes COMMAND-Verzeichnis ist falsch Befehl oder Dateiname nicht gefunden. *Main System.Cmd.rawSystem comspec [/c echo %PATH%] Angegebenes COMMAND-Verzeichnis ist falsch whether this creates any other issues I don't know:-) If you do have command.com somewhere on you system, please also test Cmd.system with your patch and COMSPEC set to command.com, as I suspect the quotes introduced in runProcessWin32 will still cause it to fail? Btw, the comment for commandToProcess refers to CreateProcess, and claims that command-line translation is undesirable: On Windows, CreateProcess takes a single string for the command, which is later decomposed by cmd.exe. In this case, we just want to prepend @\c:\WINDOWS\CMD.EXE \/c\@ to our command line. The command-line translation that we normally do for arguments on Windows isn't required (or desirable) here. We'll definitely do something about the ctrl-C issues before 6.4.1. No firm release plans yet, but we'll keep you posted. Thanks. It would be good to have some working version of 6.4 on windows, if only to convince maintainers of binary libs (like wxhaskell) to release updates.. Cheers, Claus Btw, I can produce the same effects within COMMAND.COM if I put parts of the command line in quotes (don't know whether that is a misleading coincidence or a useful hint): D:\cygwin\home\unknowncommand.com /c cd
[ ghc-Bugs-1177320 ] GHC: panic! (compiler bug?)
Bugs item #1177320, was opened at 2005-04-05 12:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1177320group_id=8032 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: GHC: panic! (compiler bug?) Initial Comment: I just tried to compile the most recent version of Pugs ( www.pugscode.org ), and I got this: Compiling Prim ( src/Prim.hs, src/Prim.o ) ghc.EXE: panic! (the `impossible' happened, GHC version 6.4): Maybe.fromJust: Nothing Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org, or http://sourceforge.net/projects/ghc/. Well, here I am, reporting this bug. The link to the Prim.hs file: http://svn.openfoundry.org/pugs/src/Prim.hs I didn't write the code, so can't really tell what's going on here, the only thing I know is that it did compile with yesterday's revision (don't know the exact number; the current svn-revision as I'm writing this is 1572). I'm running GHC 6.4 on WinXP SP2 Regards, Martin [EMAIL PROTECTED] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1177320group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: exposed package exposes dependent packages
On 05 April 2005 21:33, Duncan Coutts wrote: Over in Gentoo Haskell packaging land, while trying to get all our progs and libs to work with GHC 6.4, we came across a couple programs that were failing to compile with this error message: GetOpt.lhs:1:0: Module `GetOpt' is a member of package util-1.0. To compile this module, please use -ignore-package util-1.0. Indeed applying the fix suggested in the error message works but I don't think it is right. $ ghc-pkg field util exposed reports as we know that the old util package is not exposed by default (since it does not use hierarchical module names) So how could the GetOpt module we're trying to compile possibly clash with the GetOpt module from the util package since the util package is not exposed (and we're not compiling with -package util)? Well it turns out that we had another package installed that depends on the util package (cabal-0.5 as it happens) and that package is exposed by default. It seems that this implicitly exposes the util package. This is the right behaviour, although I agree it's a little confusing. The util package has not been exposed as a result of being depended on by cabal-0.5, but GHC has correctly inferred that it is part of the program, and so its modules cannot clash with any others in the program. The documentation does describe this (section 4.8.1): There must be no overlaps in the modules provided by all of the exposed packages, and the packages they depend on, and so on. it doesn't mention the modules of the program though. Perhaps it should, I'm open to suggestions for better wording. It would be nice if the error message said something like util-1.0 is included because it is a dependency of I'm surprised that you could use -ignore-package util, I would have expected that to cause an error due to the dependency from cabal to util. That might be a bug - can you confirm? Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: exposed package exposes dependent packages
On Tue, 2005-04-05 at 23:34 +0100, Simon Marlow wrote: Well it turns out that we had another package installed that depends on the util package (cabal-0.5 as it happens) and that package is exposed by default. It seems that this implicitly exposes the util package. This is the right behaviour, although I agree it's a little confusing. The util package has not been exposed as a result of being depended on by cabal-0.5, but GHC has correctly inferred that it is part of the program, and so its modules cannot clash with any others in the program. But it's not part of the program. In our test program we do not import any module from the dummy package (which is the exposed package that depends on util). Our example was compiling happy. happy does not import anything from cabal-0.5 and yet it was hit by this problem. Unless we consider 'part of the program' to be all modules in all exposed packages (and all modules in 'efectively exposed' packages like util via the cabal-0.5 dep). If this is not a bug, the only thing we can do is make sure we never create an ebuild for anything that installs an exposed package that depends on one of the old hslibs packages. Otherwise several other unrelated programs will fail to build. The documentation does describe this (section 4.8.1): There must be no overlaps in the modules provided by all of the exposed packages, and the packages they depend on, and so on. it doesn't mention the modules of the program though. Perhaps it should, I'm open to suggestions for better wording. So is it all modules provided by exposed packages or all modules included (directly or indirectly) in the program? It would be nice if the error message said something like util-1.0 is included because it is a dependency of That would help. We were left wondering how on earth util was getting included into the program. I'm surprised that you could use -ignore-package util, I would have expected that to cause an error due to the dependency from cabal to util. That might be a bug - can you confirm? Yes indeed. Until recently we compiled happy with -ignore-package util to work around this issue. Our new solution is to declare cabal-0.5 to be incompatible with GHC 6.4. Duncan ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
