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
