Hi Detlef,
Thanks for looking at this, but I'm afraid I'm slightly confused by your modified version of the patch ....
On Sunday 10 April 2005 10:46, Detlef Riekenberg wrote:
I'm working at wineprefixcreate also and while looking at your Patch, i found a race-condition when the user started wineprefixcreate:
wine.inf is searched first in "$datadir" and then in "$srcdatadir".
"$datadir" is "from the binary wine-tree" when wineprefixcreate was called with "--use-wine-tree" but it could also come from "the installed wine-version", when the option "--use-wine-tree" was not used.
wine.inf could be from a different wine-version in this case!
True, but this is the desirable effect, if I've understood correctly.
If the user specifies --use-wine-tree=/some/path/to/wine, then this is where she wants to get her wine.inf file from (assuming in-tree compilation).
The situation might arise if the user installs a release version of wine, but is trying out a CVS version to see if it fixes a problem. The user specifies a WINEPREFIX of ~/.wine-cvs (for example) whilst trying out the cvs version. Under these circumstances the user would want to generate the default registry using wine.inf from the CVS tree (i.e. from --use-wine-tree), and not the older values from the release wine.inf file in /usr/local (or wherever it was installed).
I can't see under what circumstance a user would specify --use-wine-tree and want to use the older, installed version of wine.inf. When would this be useful?
For out-of-tree compilation, the --use-source-tree option would be used in conjunction with the --use-wine-tree option, giving the correct result.
So, sorry I don't see the problem here. Could you explain further?
- topdir=""
- srcdatadir=""
AFAIK, this is basically a no-op unless you're up to mischief.
Under normal BASH shell expansion, there isn't a difference between an unset variable and one being empty:
paul@scaramanga:~$ unset a paul@scaramanga:~$ eval '[ ! -z "$a" ] && echo $a is $a' paul@scaramanga:~$ a="" eval '[ ! -z "$a" ] && echo $a is $a' paul@scaramanga:~$ a="some value" eval '[ ! -z "$a" ] && echo $a is $a' $a is some value
(the "eval"s are just to prevent the shell expanding the variable a before the initial assignment in the command line)
One *can* determin if a variable is set, but to me this would come under the category of "dubious activity"
paul@scaramanga:~$ eval 'set|grep -q "^a=" && echo $a is $a' paul@scaramanga:~$ a="" eval 'set|grep -q "^a=" && echo $a is $a' $a is paul@scaramanga:~$ a="some value" eval 'set|grep -q "^a=" && echo $a is $a' $a is some value
# Copy the .inf script and run it if [ -n "$topdir$srcdatadir" ] then for dir in "$topdir" "$srcdatadir"; do if [ -n "$dir" -a -e "$dir/tools/wine.inf" ]; then cp "$dir/tools/wine.inf" "$CROOT/windows/inf/wine.inf" break fi else cp "$datadir/wine.inf" "$CROOT/windows/inf/wine.inf" fi
Both $topdir and $srcdatadir are absolute directories, so the combination $topdir$srcdatadir doesn't make any sense. I *think* what you mean is something more like if [ -n "$topdir" -o -n "$srcdatadir" ]; then
I'd have slight issues with this generally as your duplicating code. OK, its just the "cp" here, but its bad form and makes code more error prone.
The duplication arises because of the previous issues with $datadir (which I think is a mistake).
I moved srcdatadir one dir-level up to use the same level as "$topdir" and to make my life more easy, because i need "$srcdatadir/documentation/samples/config" for my patches.
OK, but this does induce the code duplication above.
Perhaps, if you need to record the source-top-dir it would be better to define a $srctopdir inside the switch statement, defining $srcdatadir as $srctopdir/tools
I also noticed you made some cosmetic changes to winewrapper, but included this chunk:
@@ -106,7 +106,7 @@
if [ -z "$WINEPREFIX" -a ! -d "$HOME/.wine" ] then - if [ ! -z "$srcdir" ]; then + if [ -n "$srcdir" ]; then "$topdir/tools/wineprefixcreate" --update --use-wine-[...] else "$topdir/tools/wineprefixcreate" --update --use-wine-[...]
(kmail line wrapping be damned!)
Isn't ``[ ! -z "$var" ]'' equivalent to ``[ -n "$var" ]'' ?
Sorry, lots of questions ...
Paul.