RFC: Detecting the wine prefix

[André Hentschel]

Am 16.07.2010 11:32, schrieb Michael Stefaniuc:
> Hello Paul,
> 
> Paul Chitescu wrote:
>> I would want to implement a change in where the wine prefix is assumed by 
>> default.
>>
>> The current behavior of only considering WINEPREFIX is cumbersome and risky. 
>> 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 detects 
>> the proper prefix from the current directory and calls wine or other programs 
>> (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 to 
>> create a new prefix.
>> - Starting from current working directory descend towards root looking for a 
>> directory that:
>> 	1. Has a dosdevices/ subdirectory and a system.reg file
>>    or
>> 	2. Has a .wine symlink pointing to a directory matching condition 1.
>>    or
>> 	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 current 
>> directory is on a path that is symlinked from inside the prefix. In particular 
>> 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 a 
>> 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.
> 
> bye
> 	michael
> 
> 

Both cases should be taken into account:

user:~/.wineprefix/drive_c$ wine myapp.exe
user:~/$  wine .wineprefix/drive_c/myapp.exe

Both should work and use .wineprefix

Also dont forget about worst case situations like:

user:~/.wineA/drive_c$ WINEPREFIX=~/.wineB wine ../../.wineC/drive_c/myapp.exe

This makes clear IMHO that the env var WINEPREFIX should have the highest priority, as i think this should be started using .wineB

So i think if no WINEPREFIX is specified then the cwd should be used and if that is not in some wineprefix the apppatch should be used.

-- 

Best Regards, André Hentschel