Peter Rosin wrote:
Den 2010-08-27 00:27 skrev Roumen Petrov:
Ralf Wildenhues wrote:
Hi Charles,
[SNIP]
+ func_wine_to_win32_path_result="$1"
+ if test -n "$1"; then
+ # Unfortunately, winepath does not exit with a non-zero
+ # error code, so we are forced to check the contents of
+ # stdout. On the other hand, if the command is not
+ # found, the shell will set an exit code of 127 and print
+ # *an error message* to stdout. So we must check for both
+ # error code of zero AND non-empty stdout, which explains
+ # the odd construction:
Starting from wine 1.3.1 wine path always output paths:
I have been reading the git source of winepath, and it definitely
has code paths which output an empty result when certain things
fail (or rather, a single newline for every path/file it fails to
convert), so saying that it "always output paths" is not entirely
correct.
Lets wine is correctly configured (Z: drive is linked to the file system root):
$ cd $WINEPREFIX/dosdevices
$ winepath -w `pwd`
Z:\%WINEPREFIX_CONVERTED_TO_BACKSLASHES%\dosdevices
Now lets remove link:
$ rm z:
$ winepath -w `pwd`
\\?\unix\%WINEPREFIX_CONVERTED_TO_BACKSLASHES%\dosdevices
So sed should remove leading //?/unix
This failures are probably comping from inside wine (no mention of
"//?/unix" or "\\?\unix" in the winepath source), so probably won't
be seen as failure by winepath. But, if you silently remove \\?\unix,
then you'll end up with a path that is not complete with a drive
letter. I think any \\?\unix prefix should be filed as a failure...
Peter, are you reading this? Looks like a TODO item for
automake/lib/compile. ;-)
Yes, I'm reading this :-) Patches to compile (and ar-lib) to follow
when the dust settles...
Cheers,
Peter
FYI http://bugs.winehq.org/show_bug.cgi?id=13265
Roumen
