wine wants to open shell scripts

[Christopher Yeleighton]

Binary package hint: wine

When I Ctrl+O a non-executable shell script from Nautilus, Nautilus asks Wine to open it.

Steps to reproduce:

1. Navigate to <http://publish.skrewz.dk/encfilewrapper.sh> in Firefox.

2. Let Firefox open it with whatever it wants (see <https://bugzilla.mozilla.org/show_bug.cgi?id=196078>).

3. Navigate to the directory where temporary files are stored in Nautilus.

4. Open the file encfilewrapper.sh by double-clicking.
(Alternatively, you can gnome-open it from the command line, or Alt+F2 it).

Actual behaviour:
The X Session error log gets the following message:
wine: could not load L"Z:\\tmp\\encfilewrapper.sh": Bad EXE format for

Expected behaviour:
A text editor should open the script file.

ProblemType: Bug
Architecture: amd64
Date: Fri Feb 15 14:31:55 2008
DistroRelease: Ubuntu 7.10
NonfreeKernelModules: nvidia
Package: wine 0.9.46-0ubuntu1
PackageArchitecture: amd64
SourcePackage: wine
Uname: Linux a1dmin.vola.spe.com.pl 2.6.22-14-generic #1 SMP Tue Feb 12 02:46:46 UTC 2008 x86_64 GNU/Linux

[Scott Ritchie (scottritchie)]

Is this still the case in Hardy? I'm seeing slightly different behavior from Firefox at least (which gives me the strange option of opening it with firefox on download...)

[Jonathan Thomas (echidnaman)]

Dolphin wants to open shell scripts and python scripts with Wine by default.

[Caleb Perkins (frostmourne)]

After installing wine in Hardy, Nautilus associates all my shell and python scripts with "Wine Windows Program Loader." Even though I set Nautilus to ask me whether I want to run executable text files, wine runs the scripts automatically upon clicking. It was simple enough to change the file associations back to Text File to restore Nautilus's behavior, but this bug could have disastrous results when someone clicks on a dangerous script expecting to view it first.

[Scott Ritchie (scottritchie)]

Ok, I can now confirm this and I believe I know the source of the issue. The problem occurs with shell scripts, python scripts, ruby scripts, and possibly others.

Basically, Wine is (correctly) associated with MIME type "Application/x-executable", since this covers some .exe files (including non-Windows ones generated by Winelib). shared-mime-info classifies shell, python, and ruby scripts as sub-classes of application/x-executable, so anything that can open x-executables is used to open the scripts (in this case Wine). Since "sub-type of executable" is listed before "sub-type of text file" for scripts, handlers for executables (Wine) show up before handlers for text files, and thus Wine gets used to open it.

One possible fix is to get rid of the sub-typing in shared-mime-info. It's unlikely anything that could open "executables" should also be opening python/ruby scripts in this way (in fact Wine is probably the only program associated with executables at all). Another possible workaround is to just switch text/application so that the default becomes the text editor handler, but this leaves the problem with Wine still being listed as a handler for something it isn't.

[Scott Ritchie (scottritchie)]

Here's Wine's debian/wine.mime file:

application/x-msdos-program; /usr/bin/wine '%s'; description=Windows Executable
application/x-msdownload; /usr/bin/wine '%s'; description=Windows Executable
application/exe; /usr/bin/wine '%s'; description=Windows Executable
application/x-exe; /usr/bin/wine '%s'; description=Windows Executable
application/dos-exe; /usr/bin/wine '%s'; description=Windows Executable
vms/exe; /usr/bin/wine '%s'; description=Windows Executable
application/x-winexe; /usr/bin/wine '%s'; description=Windows Executable
application/msdos-windows; /usr/bin/wine '%s'; description=Windows Executable
application/x-msdos-program; /usr/bin/wine '%s'; description=Windows Executable
application/x-msi; /usr/bin/wine '%s'; description=Windows Installer archive

I believe application/x-exe is equivalent to application/x-executable since there's no definition of x-exe in shared-mime-info, but I haven't tested switching the two.

Here's the x-executable entry in shared-mime-info:

  <mime-type type="application/x-executable">
    <_comment>executable</_comment>
    <magic priority="40">
      <match type="string" value="\177ELF" offset="0">
        <match type="byte" value="1" offset="5">
          <match type="little16" value="2" offset="16"/>
        </match>
      </match>
      <match type="string" value="\177ELF" offset="0">
        <match type="byte" value="2" offset="5">
          <match type="big16" value="2" offset="16"/>
        </match>
      </match>
      <match type="string" value="MZ" offset="0"/>
      <match type="little16" value="0x521c" offset="0"/>
      <match type="host16" value="0420" offset="0"/>
      <match type="host16" value="0421" offset="0"/>
      <match type="little16" value="0603" offset="0"/>
    </magic>
    <glob pattern="*.exe"/>
  </mime-type>

Here's one of the relevant entries in shared-mime-info for ruby scripts (there are similar ones for python/shell scripts):

  <mime-type type="application/x-ruby">
    <sub-class-of type="application/x-executable"/>
    <sub-class-of type="text/plain"/>
    <_comment>Ruby script</_comment>
    <magic>
      <match type="string" value="/bin/env ruby" offset="1:16"/>
      <match type="string" value="/bin/ruby" offset="1:16"/>
    </magic>
    <glob pattern="*.rb"/>
  </mime-type>

I'm going to attempt a patch by switching the sub-class-of x-executable to just duplicate the magic in x-executable and see if it works. At this rate, though, it looks like another shared-mime-info bug rather than a Wine problem.

[Sebastien Bacher (seb128)]

that's an upstream issue and should be sent to bugs.freedesktop.org

[Bugs-freedesktop-org-tylerrick (bugs-freedesktop-org-tylerrick)]

When I try to open a non-executable shell script (including ruby and python scripts) from Nautilus, Nautilus asks Wine to open it.

Expected behavior:
A text editor should open the script file.

Originally reported here: https://bugs.launchpad.net/ubuntu/+source/wine/+bug/192122/ and was told to report it on bugs.freedesktop.org. So since I couldn't find the bug in the database here already, I'm reporting it.

------------------------------------------
Scott Ritchie wrote on 2008-08-01:

Ok, I can now confirm this and I believe I know the source of the issue. The problem occurs with shell scripts, python scripts, ruby scripts, and possibly others.

Basically, Wine is (correctly) associated with MIME type "Application/x-executable", since this covers some .exe files (including non-Windows ones generated by Winelib). shared-mime-info classifies shell, python, and ruby scripts as sub-classes of application/x-executable, so anything that can open x-executables is used to open the scripts (in this case Wine). Since "sub-type of executable" is listed before "sub-type of text file" for scripts, handlers for executables (Wine) show up before handlers for text files, and thus Wine gets used to open it.

One possible fix is to get rid of the sub-typing in shared-mime-info. It's unlikely anything that could open "executables" should also be opening python/ruby scripts in this way (in fact Wine is probably the only program associated with executables at all). Another possible workaround is to just switch text/application so that the default becomes the text editor handler, but this leaves the problem with Wine still being listed as a handler for something it isn't.

[Tyler Rick (tyler.rick)]

It looks like no one else has opened a bug on bugs.freedesktop.org yet, so I created one here: http://bugs.freedesktop.org/show_bug.cgi?id=20735

Also, when I encountered this bug, the results were a bit more severe than described by initial reporter:

Instead of simply logging "wine: could not load ...: Bad EXE format for" in the the X Session error log, when I accidentally opened a Ruby script with the default association (wine), my system froze up completely. I tried to move the mouse, but it wouldn't move. Within about 5-10 s of original click, I was dumped out to the Ubuntu login screen (all process apparently having been killed).

(I don't see any messages in my ~/.xsession-errors but maybe that's because it gets recreated every time I log in?)

I will try to reproduce it...

[Tyler Rick (tyler.rick)]

When I try opening the same script again with the default association (wine), nothing at all happens. I don't even see any new output at the bottom of ~/.xsession-errors (is that even the right file to be checking?)! So sorry I can't reproduce either behavior.

[Bastien Nocera (hadess-deactivatedaccount)]

Wine should use "application/x-ms-dos-executable", and there's certainly no "
    <glob pattern="*.exe"/>" for Linux executables in shared-mime-info.

[Scott Ritchie (scottritchie)]

Created an attachment (id=20846)
Reduce .desktop file to application/x-msdos-executable and application/x-msi

Our desktop file is too greedy. I think I wrote it a while back off a list of every possible mime type a .exe file can have from somewhere on the internet; this resulted in entries like x-zip-compressed and x-executable. This results in the side effect that Wine now tries to open shell scripts and zip files on many systems.

On modern systems we can rely on shared-mime-info to correctly identify executables as application/x-msdos-executable, so we only need that MIME type for .exe.

So, I suggest we reduce our .desktop file to two mime types: application/x-msdos-executable and application/x-msi. The attached patch fixes this.

This still leaves the possibility of not opening .com, .bat, or similar files, however that's already broken and is a bug in shared-mime-info to be fixed there. Moreover, there's a slight chance of the reverse possibility - a .exe file that isn't a Wine executable file. I don't think that's our bug either though - again a problem in shared-mime-info.

[Scott Ritchie (scottritchie)]

Upstream says it's our bug then. I'll remove application/x-executable from our mime type in wine.desktop.

[Steve Dodier-Lazaro (sidi)]

If you remove the application/x-executable mime type from Wine, won't it be even harder to have EXE files opened with it ?

[Scott Ritchie (scottritchie)]

shared-mime-info should be properly detecting those as application/x-ms-dos-executable now; if it isn't that's a bug they're willing to fix. Right now the current magic is to just treat all *.exe files as ms-dos-executables, which I believe is the same way that Windows itself does.

[Scott Ritchie (scottritchie)]

patch was committed to git: http://www.winehq.org/pipermail/wine-cvs/2009-May/055060.html

[Scott Ritchie (scottritchie)]

This will be fixed in Wine 1.1.21 (and thusly Wine 1.2), so it'll make its way into Karmic.

[Alexandre Julliard (julliard)]

Closing bugs fixed in 1.1.21.