the .exe extension

[Eric Blake]

On 03/12/2010 08:03 AM, Nellis, Kenneth wrote:
> I wonder if there is more explanation available about how Cygwin
> handles the .exe extension than I found in the User's Guide.
> 
> http://cygwin.com/cygwin-ug-net/
> 
> I'm running 1.7.1.
> In particular, I find it odd that moving a binary executable
> toggles whether or not it has the .exe extension. Consider:
> 
> $ ls -l
> total 8
> -rwxr-x--- 1 knellis knellis 4096 2010-03-12 09:08 a.exe
> -rwxr-x--- 1 knellis knellis 4096 2010-03-12 09:37 b
> $ mv a c
> $ mv b d
> $ ls -l
> total 8
> -rwxr-x--- 1 knellis knellis 4096 2010-03-12 09:08 c
> -rwxr-x--- 1 knellis knellis 4096 2010-03-12 09:37 d.exe
> $

This is an area of active conversation; if you would like, you can test
the latest snapshot and the experimental coreutils 8.4-1 to see if the
behavior is more intuitive (that is, there are more situations where
.exe is preserved across file moves or copies, and fewer places where
.exe is appended on a whim if the source didn't have one).

In general, cygwin does not care if the .exe is missing, but other
programs (particularly cmd) do, so it is better if PE-COFF files are
given the .exe extension.  But implementing it is tricky - for example,
in the case of 'cat a > b', there is no way to tell at the time when b
is created whether it will be populated with PE-COFF contents (that is,
no way to tell whether the source was a literal 'a' or 'a.exe'), so you
will not get an .exe in that case.

> 
> I have a mixture of binaries with and without the .exe extension
> and wonder if the mixture will somehow bite me one day.

Hopefully not, but feel free to report any test cases where things need
to be improved.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 323 bytes
Desc: OpenPGP digital signature
URL: <http://cygwin.com/pipermail/cygwin/attachments/20100312/08cbc687/attachment.sig>