From: SourceForge.net <no...@so...> - 2004-08-31 12:49:23
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2737311 By: keithmarshall MinGW GCC adds the .exe extension, so that the resulting executable will run under the MS-Windows' native shell (cmd.exe) -- if you remove the extension, then cmd.exe will *not* run the executable! The fault lies not in MinGW GCC, but in the flex Makefile, which has not been coded for portability to the MS-Windows platform. Instead of referring to the flex executable as simply 'flex', it *should* use 'flex$(EXEEXT)', and the configure script should run the AC_EXEEXT autoconf test, to set $(EXEEXT) appropriately. This, of course, assumes that the flex project uses GNU autoconf to manage the configuration process. If it doesn't, then perhaps you should 'autoconfiscate' it, (or respectfully suggest to its maintainers that they do so). Otherwise, you will need to code the proper handling of $(EXEEXT) yourself, by hand. Regards, Keith. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2004-08-31 13:09:49
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2737353 By: johngaughan > So question - why gcc appends "exe"? That extension is the standard Win32 way of saying "this file is executable code." > For instance this breaks makefile for flex - it can't install flex > and create link to flex++ since under mingw one get flex.exe instead > of flex. Create a variable in your makefile for the output file. Use this variable wherever you need it and include the extension in Windows. EXEFILE=file.exe gcc ... $(EXEFILE) flex ... $(EXEFILE) ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2004-08-31 19:38:31
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2737986 By: cdsontag Does anyone know if there is a way to prevent the ".exe" extension via gcc, if only for use inside of Cygwin ? ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2004-08-31 21:03:12
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2738113 By: johngaughan I don't know about preventing the extension, but you could always put "mv file.exe file" in your makefile. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2004-09-01 08:16:13
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2738753 By: keithmarshall You shouldn't do that! MS-Windows *needs* the .exe extension, to mark the application file as executable, since there is no file attribute for this purpose. A Cygwin application may be invoked directly from the Windows environment, even without having the Cygwin bash.exe shell running, but Windows itself needs to know that the file is executable; the .exe extension is what tells it! Although, the Cygwin bash.exe, and the MSYS sh.exe for that matter, may *allow* you to drop the extension, and still be able to execute the application, you will not then be able to invoke it from a native MS-Windows environment. As I stated yesterday, the proper way to handle this is to construct the Makefile so that the extension is handled by a *variable*, in the manner employed by GNU autoconf, with its $(EXEEXT) variable -- and why else would you *need* to remove the extension? The exec and spawn functions used by both Cygwin and MinGW will append it automatically to any bare file name specified, when searching for a program file to invoke a process! ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2004-09-01 12:27:32
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2739039 By: cdsontag Easy big fella. I understand your point about Windows accepting it. My question (pretty clearly I thought) was concerning binaries only being run from inside of Cygwin (bash). I don't really care if I am able to "invoke it from a native MS-Windows environment". Thanks for the info though. Thanks also to John for the renaming post - that is what I have been doing so far. I am working with legacy shell scripts that cannot be changed. Don't ask why. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: Christopher F. <me...@cg...> - 2004-09-01 14:41:20
|
On Wed, Sep 01, 2004 at 05:27:29AM -0700, SourceForge.net wrote: >Thanks also to John for the renaming post - that is what I have been doing so >far. I am working with legacy shell scripts that cannot be changed. Don't >ask why. Just an FYI, this should work too: gcc -o foo. foo.c This creates a "foo" without the .exe extension. cgf |
From: SourceForge.net <no...@so...> - 2004-09-01 13:46:58
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2739144 By: keithmarshall You are *still* missing the point! So you have a legacy shell script, which invokes some binary application, called "someapp". When you compile this application, using the Cygwin or the MinGW implementation of GCC, the executable becomes "someapp.exe". When your shell script, running under Cygwin bash.exe, tries to invoke "someapp", (without the .exe extension), it will look for "someapp.exe" anyway. So, you are better to stick with the Windows convention of having binary executables marked as such, by keeping the .exe extension. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: Christopher F. <me...@cg...> - 2004-09-01 14:42:55
|
On Wed, Sep 01, 2004 at 06:46:55AM -0700, SourceForge.net wrote: >Read and respond to this message at: >https://sourceforge.net/forum/message.php?msg_id=2739144 >By: keithmarshall > >You are *still* missing the point! > >So you have a legacy shell script, which invokes some binary application, called >"someapp". When you compile this application, using the Cygwin or the MinGW >implementation of GCC, the executable becomes "someapp.exe". When your shell >script, running under Cygwin bash.exe, tries to invoke "someapp", (without the >.exe extension), it will look for "someapp.exe" anyway. So, you are better >to stick with the Windows convention of having binary executables marked as >such, by keeping the .exe extension. Running a program without the .exe extension should work fine on Windows NT and its derivatives. It works fine in cygwin on XP. I just tried it. cgf |
From: SourceForge.net <no...@so...> - 2004-09-01 16:02:48
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2739569 By: keithmarshall In response to this thread, Christopher Faylor noted, on the MinGW-users mailing list, that an executable *without* the .exe extension should run ok under WinNT and its derivatives, and indeed it will, *provided* it is started from the command prompt in a Cygwin or MinGW shell, or within a script run by either of these shells. My point, however, is that it will *not* run if you try to start it from a cmd.exe prompt, or from a Windows desktop shortcut, if the .exe extension is missing. Since *both* Cygwin and MinGW shells will run a program equally well whether the extension is present or not, it is surely better to adhere to the Windows standard of naming executables *with* the .exe extension. The whole point is, of course moot, when a program is run exclusively from a script, which requires either the Cygwin or MinGW shell, or some other Bourne shell compatible alternative, to interpret it in the first place. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: Christopher F. <me...@cg...> - 2004-09-02 01:46:28
|
On Wed, Sep 01, 2004 at 09:02:09AM -0700, SourceForge.net wrote: >In response to this thread, Christopher Faylor noted, on the >MinGW-users mailing list, that an executable *without* the .exe >extension should run ok under WinNT and its derivatives, and indeed it >will, *provided* it is started from the command prompt in a Cygwin or >MinGW shell, or within a script run by either of these shells. > >My point, however, is that it will *not* run if you try to start it >from a cmd.exe prompt, or from a Windows desktop shortcut, if the .exe >extension is missing. Actually, if you create a program called "t", you can run it from the command prompt by typing "t." NT+ really doesn't care. >Since *both* Cygwin and MinGW shells will run a program equally well >whether the extension is present or not, it is surely better to adhere >to the Windows standard of naming executables *with* the .exe >extension. I assume that you are referring to msys when you mention the "MinGW shell". Since msys pretty much == cygwin, it isn't surprising that they behave similarly. (Sorry, but I can't stop making this point since it isn't always clear that people understand that msys is a cygwin derivative). Anyway, I don't understand the continued insistence on adding a .exe extension. If it works ok for your environment, and you understand all of the risks, I don't see any reason to vehemently insist that one should add a .exe. cgf |
From: Stephen R. <st...@mr...> - 2004-09-02 02:11:44
|
Christopher Faylor wrote: > > Actually, if you create a program called "t", you can run it from the > command prompt by typing "t." NT+ really doesn't care. > That definitely does not work on my Windows XP system. Is there some setting you change to get that to work? |
From: Christopher F. <me...@cg...> - 2004-09-02 02:30:48
|
On Wed, Sep 01, 2004 at 11:11:42PM -0300, Stephen Ray wrote: >Christopher Faylor wrote: >>Actually, if you create a program called "t", you can run it from the >>command prompt by typing "t." NT+ really doesn't care. > >That definitely does not work on my Windows XP system. Is there some >setting you change to get that to work? Oops. I use 4/NT - http://www.jpsoft.com/4ntdes.htm . You're right. It doesn't seem to work with the standard CMD shell. Sorry. cgf |
From: Earnie B. <ea...@us...> - 2004-09-02 09:53:25
|
Stephen Ray wrote: > Christopher Faylor wrote: > >> >> Actually, if you create a program called "t", you can run it from the >> command prompt by typing "t." NT+ really doesn't care. >> > > That definitely does not work on my Windows XP system. Is there some > setting you change to get that to work? You can grab the gcc source and remove the ld switch --force-exe-suffix and build you own version. Or just remember to always use the period character on the output file name. I don't thing a negative to --force-exe-suffix exists. Earnie -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438 |
From: Jeremy B. <je...@de...> - 2004-09-02 02:55:14
|
> Anyway, I don't understand the continued insistence on adding a .exe > extension. If it works ok for your environment, and you understand all > of the risks, I don't see any reason to vehemently insist that one > should add a .exe. Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\Users\jeremy>foo 'foo' is not recognized as an internal or external command, operable program or batch file. C:\Users\jeremy>copy c:\windows\notepad.exe foo 1 file(s) copied. C:\Users\jeremy>foo 'foo' is not recognized as an internal or external command, operable program or batch file. C:\Users\jeremy>ren foo foo.exe C:\Users\jeremy>foo (notepad opens) The insistance of the .exe is because windows requires it. Just because cygwin and msys choose to break the rules, does not mean that the rules don't exist. Besides this is the MINGW mailing list, and the MINGW complier creates executables for NATIVE windows. |
From: Christopher F. <me...@cg...> - 2004-09-02 15:21:26
|
On Wed, Sep 01, 2004 at 09:54:52PM -0500, Jeremy Bettis wrote: >The insistance of the .exe is because windows requires it. Just >because cygwin and msys choose to break the rules, does not mean that >the rules don't exist. Cygwin uses the standard Windows CreateProcess call to start a program so it really can't be breaking the rules unless you are saying that Microsoft itself is breaking the rules. There is also at least one other command shell which works as described. The "rules" that you are referring to are limitations imposed by cmd.exe. Amusingly enough, if you rename foo.exe to foo.txt, you can still execute the command as .\foo.txt. It just doesn't work if you rename to .\foo. >Besides this is the MINGW mailing list, and the MINGW complier creates >executables for NATIVE windows. Um, yeah, wow, what an excellent point. I had a lapse for a minute and thought I was in an origami mailing list. I agree that the best way to ensure portability is to use EXEEXT in your Makefiles and stick with the .exe extension. I was just showing someone how to produce an executable without a .exe extension and wondering why, when they seemed to get the fact that there are pitfalls in doing so, they were still being told about the pitfalls. Keith understood this. FWIW, it would be trivial to write a program for NT which uses CreateProcess to run other programs sans executable extensions but it's hard to see how that would be useful. |
From: SourceForge.net <no...@so...> - 2004-09-01 17:27:43
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2739710 By: cdsontag In fact, I am NOT missing your point - you have made it so many times you haven't considered what I'm saying. My legacy script does more than run the binary. It looks for it first, using the name without ".exe" on the end. Again - its legacy - I can't fix it, strange as it is. Thanks anyway for your passionate responses, Keith. Thanks also to Chris F. for the "gcc -o foo." idea! ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2004-09-02 14:26:55
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2741442 By: akovalev Hello Keith, thanks for explanation. I also believe that flex should be fixed for better portability. However the same question could be addressed to gcc under mingw - specifically I think that it's maintaner resposibility to create makefile which will tell gcc to generate executables with *.exe extension (or without it) using exactly the same way you proposed for flex. It seems to me that's correct flexible way to maintain software instead of patching gcc. May be where is some fundamental problem in mingw environment which requires such gcc patch? Also there's rare possibility to run into silly problem - say if you sources have file with "*.exe" name then following compilation will override such source with binary: # h.exe is C source code gcc -xc h.exe -o h Yes, that's really rare but it breaks definitive behaviour. -Alexey ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |
From: SourceForge.net <no...@so...> - 2004-09-02 16:01:22
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2741626 By: keithmarshall Hi Alexey, Silly problem indeed. IMHO, if you use GCC's -x switch the way you suggest, then you are asking for trouble. On Windows, *.exe means binary executable -- don't try to force GCC to treat it as anything else. If you stick to recognised conventions, then you won't go wrong. I fully agree with you, that it would be nice if program maintainers would create makefiles which properly anticipate a .exe extension for executables on Windows, but transparently omit it on *nix. Some do, some unfortunately don't. Those who employ the GNU autotools get a head start in the right direction, if they include AC_EXEEXT in configure.ac, and EXEEXT=@EXEEXT@ in Makefile.in. Regards, Keith. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=286529 |