I *almost* have a great success story to report; the only thing keeping it from being a success story is the current directory chosen by Nautilus when double-clicking on .exe files.
My wife hurt a finger trying to impersonate a Sampsonite Luggage gorilla, and had to go to a hand doctor. Along the way her hand got x-rayed, and the doctor handed her a cd-rom with the x-ray pictures on it. The disc has an autorun.inf on it that should start ViewSel.exe. I don't know if that's supposed to work with Wine and Nautilus, but probably doubleclicking on ViewSel.exe does the same thing.
ViewSel.exe puts up two big buttons: low res (which launches a web browser on an html file), and high res (which launches a DICOM viewer). If you cd to the root of the cd-rom drive and run ViewSel, it works. If the current directory is anything else, it doesn't work.
If you start the autorun app via Nautilus, those buttons don't work, so presumably it sets the current directory to something other than the root of the drive. To see, I created a wrapper shell script, ~/bin/mywine, containing #!/bin/sh pwd > /tmp/log and used "Start with" to launch ViewSel.exe with ~/bin/mywine. This showed that the current directory was $HOME.
I had a look at the gnome code to see how it decided, but it was a bit hard to follow. (See gnome_vfs_mime_application_launch_with_env.) So I tried a little shell magic. I created a new wrapper shell script that assumes the argument is a path to a file, and sets the current directory to the directory containing that file:
#!/bin/sh DIR=`dirname "$1"` DIR=`cd "$DIR"; pwd` cd "$DIR" wine "$@"
That worked better; it let ViewSel.exe launch the DICOM viewer.
So... I suppose the next step is to look at the debian/ubuntu packages for wine and see if that little wrapper script could be incorporated into the default way file browsers start wine? It sure would be nice if apps that expected the current directory to behave like this (it's not uncommon!) Just Worked. - Dan
On Fri, 2007-04-06 at 23:01 -0700, Dan Kegel wrote:
I *almost* have a great success story to report; the only thing keeping it from being a success story is the current directory chosen by Nautilus when double-clicking on .exe files.
My wife hurt a finger trying to impersonate a Sampsonite Luggage gorilla, and had to go to a hand doctor. Along the way her hand got x-rayed, and the doctor handed her a cd-rom with the x-ray pictures on it. The disc has an autorun.inf on it that should start ViewSel.exe. I don't know if that's supposed to work with Wine and Nautilus, but probably doubleclicking on ViewSel.exe does the same thing.
ViewSel.exe puts up two big buttons: low res (which launches a web browser on an html file), and high res (which launches a DICOM viewer). If you cd to the root of the cd-rom drive and run ViewSel, it works. If the current directory is anything else, it doesn't work.
If you start the autorun app via Nautilus, those buttons don't work, so presumably it sets the current directory to something other than the root of the drive. To see, I created a wrapper shell script, ~/bin/mywine, containing #!/bin/sh pwd > /tmp/log and used "Start with" to launch ViewSel.exe with ~/bin/mywine. This showed that the current directory was $HOME.
I had a look at the gnome code to see how it decided, but it was a bit hard to follow. (See gnome_vfs_mime_application_launch_with_env.) So I tried a little shell magic. I created a new wrapper shell script that assumes the argument is a path to a file, and sets the current directory to the directory containing that file:
#!/bin/sh DIR=`dirname "$1"` DIR=`cd "$DIR"; pwd` cd "$DIR" wine "$@"
That worked better; it let ViewSel.exe launch the DICOM viewer.
So... I suppose the next step is to look at the debian/ubuntu packages for wine and see if that little wrapper script could be incorporated into the default way file browsers start wine? It sure would be nice if apps that expected the current directory to behave like this (it's not uncommon!) Just Worked.
- Dan
Which version of nautilus (err.. Gnome) were you using? The one in Edgy or Feisty?
I ask, because Edgy seems to not want to run executables at all from double clicking, producing this horrendous error: http://tuzakey.com/~scott/wine_without_mime.png
I've been told the above is a bug in nautilus. At any rate, it partially resulted from removing the MIME contents of Wine from the packages; this was done for security purposes, and because binfmt-support is supposed to launch the app with Wine. You'll notice in the above image that it does indeed identify the application correctly - nautilus just fails to launch it.
That said, I maintain the Ubuntu packages, and if you've got a fix I can use, I'll certainly incorporate it.
Thanks, Scott Ritchie
Ran into this again today. I usually launch everything from the commandline, but in preparation for my cebit talk, I started trying to use the GUI and just double- click on apps in Nautilus. (This is Ubuntu 8.10.) Works fine until I try it with the setup.exe in the directory created by the Adobe Photoshop CS2 downloadable trial... at which point it aborts early with a dialog box.
The little script I posted before still works, and lets photoshop's inner installer run.
I suppose this script isn't the final word, though, as I think it will prevent switching discss on multidisc installs. - Dan
On Fri, Apr 6, 2007 at 10:01 PM, Dan Kegel [email protected] wrote:
I *almost* have a great success story to report; the only thing keeping it from being a success story is the current directory chosen by Nautilus when double-clicking on .exe files.
My wife hurt a finger trying to impersonate a Sampsonite Luggage gorilla, and had to go to a hand doctor. Along the way her hand got x-rayed, and the doctor handed her a cd-rom with the x-ray pictures on it. The disc has an autorun.inf on it that should start ViewSel.exe. I don't know if that's supposed to work with Wine and Nautilus, but probably doubleclicking on ViewSel.exe does the same thing.
ViewSel.exe puts up two big buttons: low res (which launches a web browser on an html file), and high res (which launches a DICOM viewer). If you cd to the root of the cd-rom drive and run ViewSel, it works. If the current directory is anything else, it doesn't work.
If you start the autorun app via Nautilus, those buttons don't work, so presumably it sets the current directory to something other than the root of the drive. To see, I created a wrapper shell script, ~/bin/mywine, containing #!/bin/sh pwd > /tmp/log and used "Start with" to launch ViewSel.exe with ~/bin/mywine. This showed that the current directory was $HOME.
I had a look at the gnome code to see how it decided, but it was a bit hard to follow. (See gnome_vfs_mime_application_launch_with_env.) So I tried a little shell magic. I created a new wrapper shell script that assumes the argument is a path to a file, and sets the current directory to the directory containing that file:
#!/bin/sh DIR=`dirname "$1"` DIR=`cd "$DIR"; pwd` cd "$DIR" wine "$@"
That worked better; it let ViewSel.exe launch the DICOM viewer.
So... I suppose the next step is to look at the debian/ubuntu packages for wine and see if that little wrapper script could be incorporated into the default way file browsers start wine? It sure would be nice if apps that expected the current directory to behave like this (it's not uncommon!) Just Worked.
- Dan
2009/2/15 Dan Kegel [email protected]:
Ran into this again today. I usually launch everything from the commandline, but in preparation for my cebit talk, I started trying to use the GUI and just double- click on apps in Nautilus. (This is Ubuntu 8.10.) Works fine until I try it with the setup.exe in the directory created by the Adobe Photoshop CS2 downloadable trial... at which point it aborts early with a dialog box.
The little script I posted before still works, and lets photoshop's inner installer run.
I suppose this script isn't the final word, though, as I think it will prevent switching discss on multidisc installs.
Probably. It's worth trying out, but I have an idea to work around it:
#!/bin/sh DIR=`dirname "$1"` DIR=`cd "$DIR"; pwd` pushd "$DIR" wine "$@" & popd fg
Could someone try this out? I'm not sure if I have any multi-CD installers easily accessible. Of course, you'll need some way to run "wine eject" when switching discs ...
On Sat, Feb 14, 2009 at 2:33 PM, Ben Klein [email protected] wrote:
Probably. It's worth trying out, but I have an idea to work around it:
#!/bin/sh DIR=`dirname "$1"` DIR=`cd "$DIR"; pwd` pushd "$DIR" wine "$@" & popd fg
I don't think that'll help, offhand.
Maybe the original script will work just fine, I'll see if I can find a multi-disc game to test.
2009/2/15 Dan Kegel [email protected]:
On Sat, Feb 14, 2009 at 2:33 PM, Ben Klein [email protected] wrote:
Probably. It's worth trying out, but I have an idea to work around it:
#!/bin/sh DIR=`dirname "$1"` DIR=`cd "$DIR"; pwd` pushd "$DIR" wine "$@" & popd fg
I don't think that'll help, offhand.
Well, I suppose it would depend where the script is run from. If the problem is the shell staying in the CD directory until wine finishes, it should fix it. An alternative would be to replace pushd/popd with: cd "$DIR" and cd respectively ...
Maybe the original script will work just fine, I'll see if I can find a multi-disc game to test.
Let me know :)
Dan Kegel wrote:
Ran into this again today. I usually launch everything from the commandline, but in preparation for my cebit talk, I started trying to use the GUI and just double- click on apps in Nautilus. (This is Ubuntu 8.10.) Works fine until I try it with the setup.exe in the directory created by the Adobe Photoshop CS2 downloadable trial... at which point it aborts early with a dialog box.
The little script I posted before still works, and lets photoshop's inner installer run.
What happened with 'wine start /unix %f'? Doesn't it work for you?
Vitaliy.
On Sat, Feb 14, 2009 at 6:04 PM, Vitaliy Margolen [email protected] wrote:
What happened with 'wine start /unix %f'? Doesn't it work for you?
It turns out that having cxchromium installed does interesting things to nautilus's treatment of .exe files.
I think uninstalling cxchromium made things work better.
For reference:
dpkg-query -L wine | grep mime shows that the ubuntu wine package is creating a file /usr/lib/mime/packages/wine which contains lines like
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 ...
and I presume that's what's controlling the doubleclick action on .exe's now that I've uninstalled cxchromium. - Dan
Dan Kegel wrote:
dpkg-query -L wine | grep mime shows that the ubuntu wine package is creating a file /usr/lib/mime/packages/wine which contains lines like
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 ...
That's clearly invalid and not what wine.desktop contains. I'd call it a downstream bug which needs to be fixed in ubuntu.
Vitaliy.
On Sat, Feb 14, 2009 at 10:09 PM, Vitaliy Margolen [email protected] wrote:
Dan Kegel wrote:
dpkg-query -L wine | grep mime shows that the ubuntu wine package is creating a file /usr/lib/mime/packages/wine which contains lines like
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
That's clearly invalid and not what wine.desktop contains. I'd call it a downstream bug which needs to be fixed in ubuntu.
Oddly, though, it works for me in the one app I tried it on.
Do you know of an app that will make the bug obvious, offhand?
Thanks, Dan
-
Ben Klein -
Dan Kegel -
Scott Ritchie -
Vitaliy Margolen