RFC: Detecting the wine prefix

[Paul Chitescu]

Hi!

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?

Paul Chitescu

[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:
> - 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

[Scott Ritchie]

On 07/16/2010 02:32 AM, 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:
> > - 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.

This seems the more sensible approach, particularly in the case of old
.desktop entries that don't, to my knowledge, set the wine prefix.

Thanks,
Scott Ritchie

[Paul Chitescu]

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:
> > - 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

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>

Paul

[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:
> > > - 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

[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:
> > - 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.

[Michael Stefaniuc]

On 07/16/2010 04:58 PM, André Hentschel wrote:
> 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:
> > > - Has a dosdevices/ subdirectory and a system.reg file
> > > or
> > > - Has a .wine symlink pointing to a directory matching condition 1.
> > > or
> > > - 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.
> Both cases should be taken into account:

That's what I said.
> 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.

The second part is wrong.
If the user *explicitly* requests something we have to honor it. So
- Highest priority: WINEPREFIX aka "I know what I'm doing, stop ASSuming 
and do what I tell you to do!"
- Second highest priority: application path. The user explicitly passes 
that to Wine; we have to honor that.
- Last priority: current working directory. This actually is needed 
*only* for stuff like "wineconsole cmd" or "winetricks bla" as "wine 
foo.exe" already specifies the path to the app and is handled by the 
second rule.

bye
    michael