Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#2248 closed bug (fixed)

.exe extension missing when compiling a file ending in dot + digits + dot hs

Reported by: oboudry Owned by: simonmar
Priority: normal Milestone: 6.10 branch
Component: Compiler Version: 6.8.2
Keywords: driver081.* Cc: olivier.boudry@…, ndmitchell@…
Operating System: Windows Architecture: x86
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


Hi all,

I just encountered this very minor bug on Windows/GHC 6.8.2

When compiling a file that ends in .N.hs where N is a series of digits, the executable is missing the .exe extension.

I can of course workaround the problem by specifying the file name with the -o flag.

Here is a series of test I made to determine when the bug occurs. Look at the Linking ... line that shows the executable name.

C:\Temp\Haskell>ghc --make Test_0.hs
[1 of 1] Compiling Main             ( Test_0.hs, Test_0.o )
Linking Test_0.exe ...

C:\Temp\Haskell>ren Test_0.hs Test.0.hs

C:\Temp\Haskell>ghc --make Test.0.hs
[1 of 1] Compiling Main             ( Test.0.hs, Test.0.o )
Linking Test.0 ...

C:\Temp\Haskell>ren Test.0.hs Test.012.hs

C:\Temp\Haskell>ghc --make Test.012.hs
[1 of 1] Compiling Main             ( Test.012.hs, Test.012.o )
Linking Test.012 ...

Best regards,


Change History (8)

comment:1 Changed 9 years ago by igloo

difficulty: Unknown
Milestone: 6.10 branch

What we currently do is to add a .exe extension if there is no extension already. In your examples you already have an extension (.0 or .012).

The code is trivial to change, it's just a question of what behaviour we want. If we do change the behaviour, what extensions should mean that we don't add .exe? Obviously .exe should, but what about, e.g., .scr?

comment:2 Changed 9 years ago by oboudry

Ok, I see. There are so many executable extension in Windows that it's probably better to leave it as it is and close this bug report. I just thought about .exe when creating this bug report.

comment:3 Changed 9 years ago by igloo

Resolution: invalid
Status: newclosed

OK, thanks for the reply! No other opinions, so I'll close the ticket.

comment:4 Changed 9 years ago by NeilMitchell

Cc: ndmitchell@… added
Resolution: invalid
Status: closedreopened

The executable extensions are given by the environment variable %PATHEXT%. On Vista:


I'm not entirely convinced GHC is doing the right thing here though. I think there are two entirely separate cases which are being treated equivalently:

1) Not specifying -o. ghc --make <name>.hs should create "<name>.exe". Even ghc --make Main.exe.hs should create Main.exe.exe. This fixes this bug in a clean way, without knowledge of which extensions are executable.

2) Specifying -o. ghc -o <name> should create <name>.exe unless name already has an extension. i.e. -o foo.123 produces foo.123, but -o foo produces foo.exe. This maintains existing behaviour.

I suspect this is being implemented as ghc --make <name>.hs is translated to ghc --make <name>.hs -o <name>, which is merging the behaviour of the two cases, and getting the first case (in this bug) wrong.

comment:5 Changed 9 years ago by oboudry

I agree with Neil on #1. Not specifying -o on Win32 should always append the .exe extension. I don't think people would "code" the extension in the file name (I may be wrong).

On case #2 it looks like GHC already does what Neil specified and that works fine for me.

comment:6 Changed 9 years ago by simonmar

Owner: set to simonmar
Status: reopenednew

comment:7 Changed 9 years ago by simonmar

Keywords: driver081.* added
Resolution: fixed
Status: newclosed


comment:8 Changed 9 years ago by simonmar

Fri Jul 11 08:11:46 PDT 2008  Simon Marlow <>
  * FIX #2248
  Unconditionally add .exe to the output executable name when using
  --make on Windows, and no -o option was given.
Note: See TracTickets for help on using tickets.