RFC: Detecting the wine prefix

[Michael Stefaniuc]

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 
>>> 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.
>>
 > Right.
> 
> <can-of-worms>
> 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.
> </can-of-worms>
Not really a problem as those are just shell script wrappers that
translate, e.g.
  winedbg $program
to
  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.

bye
	michael