RFC: Detecting the wine prefix
mstefani at redhat.com
Fri Jul 16 07:11:51 CDT 2010
Paul Chitescu wrote:
> On Friday 16 July 2010 12:32:33 pm Michael Stefaniuc wrote:
>> Hello Paul,
>> Paul Chitescu wrote:
>>> I would want to implement a change in where the wine prefix is assumed by
>>> The current behavior of only considering WINEPREFIX is cumbersome and
>>> Slip a finger, forget a letter and you end running a potential disastrous
>>> command in the wrong prefix. I ruined my main prefix by accidenatlly running
>>> "winetricks ie6" in it...
>>> To fix that I use a wrapper script (unimaginatively named "win") that
>>> the proper prefix from the current directory and calls wine or other
>>> (winecfg, wineserver, winetricks, etc.) after setting WINEPREFIX. I am
>>> satisfied by this wrapper but has several disadvantages:
>>> - You need to remember to run it instead of wine.
>>> - You may paste a command from somewhere and forget to add "win" in front.
>>> - Needs to be distributed.
>>> The proposed solution is to incorporate the prefix detection logic in wine
>>> itself so no wrapper is needed.
>>> The modified behavior would be like this:
>>> - If WINEPREFIX is set obey that, user knows better. This is also required
>>> create a new prefix.
>>> - Starting from current working directory descend towards root looking for
>>> directory that:
>>> 1. Has a dosdevices/ subdirectory and a system.reg file
>>> 2. Has a .wine symlink pointing to a directory matching condition 1.
>>> 3. Holds a .wine regular file whose content is the name of a directory
>>> matching condition 1.
>>> - If a valid prefix (matches condition 1. above) is found use it for wine
>>> - Else use the default ~/.wine
>>> The extra checks 2. and 3. are to be able to handle the case when the
>>> directory is on a path that is symlinked from inside the prefix. In
>>> test 3. is used when the files are on a FAT (or other symlink incapable)
>>> partition. I have several wine prefixes whose "Program Files" is located on
>>> much larger FAT32 partition shared with you know what.
>>> What do you think about this? Should I go on coding it?
>> I like the idea as it follows the DWIM (Do What I Mean) principle.
>> But the working directory shouldn't be the primary means to detect what
>> WINEPREFIX to use. That should be inherited first from the location of
>> the Win32 binary that is run. E.g. working on multiple regression bugs I
>> have used a separate git tree as well as a separate WINEPREFIX per bug.
>> My CWD was always the SRCDIR/BUILDIR thus useless to find the WINEPREFIX
>> but the path to the binary always had the WINEPREFIX informations in it:
>> ./wine ~/wine/prefixes/21409/drive_c/Program\ Files/foo/foo.exe
>> The "descend towards root" is used extensively by git so that one can
>> provide a good inspiration on how to do it, especially the corner cases.
> A problem here would be to detect an executable name is present on the command
> line - and not only for wine but for other commands like winedbg and
> wineconsole too.
Not really a problem as those are just shell script wrappers that
wine winedbg $program
So you can either handle that in the wrapper of the handful of scripts
that should do that or have a list of wine commands that need that
handling in the wine loader.
More information about the wine-devel