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