Hi Alan,
that is wonderful! My guess as to the subtleties of the two forms of
paths is that bash (or any shell) under MinGW/MSYS recognises the
/z/path/to/file form and _converts_ it to z:\path\to\file (or one with
/'s), to make sure that ordinary programs that assume the DOS form of
absolute paths continue to work (forward slashes usually work as well!).
I just checked it with a small program:
/* chkpath.c --
Check the path as provided by bash
*/
#include <stdio.h>
int main(int argc, char *argv[] ) {
printf( "Argument 0: %s\n", argv[0] );
printf( "Argument 1: %s\n", argv[1] );
}
The result of "chkpath /a/b" was:
Argument 0: d:\plplot-svn\test-drvdir\chkpath.exe
Argument 1: d:/MinGW2010/msys/1.0/a/b
Whereas when I run "chkpath a:/a/b" the result is:
Argument 0: d:\plplot-svn\test-drvdir\chkpath.exe
Argument 1: a:/a/b
If I run "chkpath /d/b" (so with a drive letter that corresponds
to an actual drive) I get:
Argument 0: d:\plplot-svn\test-drvdir\chkpath.exe
Argument 1: d:/b
Conclusion: the shell is performing all manner of magical tricks
to make sure the UNIX and Windows conventions both work!
Regards,
Arjen
On 2010-12-17 08:28, Alan W. Irwin wrote:
> On 2010-12-16 11:35-0800 Alan W. Irwin wrote:
>
>> The bad C results on wine show the error has nothing to do with Tcl
>> which is a nice simplification, but the corresponding good results on
>> Linux show it must be some Windows-specific issue. On the other hand,
>> the good C results using the -o option on wine prove bash and C and
>> PLplot can handle long filenames on wine with no issues.
>>
>> Thus, all the symptoms are consistent with the hypothesis that for the
>> special case where the user must be prompted for a filename, the C
>> (and Tcl) examples call a PLplot function to open the file in a
>> peculiar way which has a Windows-specific filename length limitation.
>> That hypothesis does seem pretty improbable if you think about
>> it, but as Sherlock Holmes said: "Eliminate all other factors, and the
>> one which remains must be the truth."
>>
>> That should be enough experimentation, and it is now time to start
>> debugging the code to see whether the above hypothesis is true.
>> Fortunately,
>> MSYS gives you access to the gcc debugger, gdb, which is an excellent
>> tool for debugging.
>
> Hmm. Holmesian logic only works if you truly have eliminated all
> other possibilities, and this was not the case here. It wasn't a
> question of the length of the pathname. Instead, it was a question
> of whether the pathname was relative or absolute. For the case
> of the prompted filename that was absolute, the drive letter
> form is fine, but not the alternative (available under bash) of
> the leading-slash form of absolute filename.
>
> For example,
>
> echo z:/tmp/test.ps |./x10c -dev psc
>
> works without issues, but using the /z prefix fails:
>
> echo /z/tmp/test.ps |./x10c -dev psc
> Enter graphics output file name: Can't open /z/tmp/test.ps.
> Can't open /z/tmp/test.ps.....
>
> Furthermore,
>
> ./x10c -dev psc -o /z/tmp/test.ps
>
> _does_ work despite that /z prefix, and if you use the -debug option, you
> find it successfully opens z:/tmp/test.ps rather than the specified
> /z/tmp/test.ps! However, if you try to use that -o option in a gdb
> environment, e.g.,
>
> gdb ./x10c
> run -dev psc -o /z/tmp/test.ps
>
> it fails with the "Can't open /z/tmp/test.ps" message. So there are
> some really subtle interactions going on here in a bash/gdb/windows
> environment which provide a wide variety of failing or succeeding
> results depending on minute details of exactly what is done with
> absolute pathnames and how various software components recognize
> the leading / form (or not in the gdb case).
>
> In all cases the drive letter form works, but I didn't want to
> complicate our C code to transform the leading slash form to drive
> letter form for the Windows case. So I have worked around this issue
> (revision 11374) by using a sed script (sed is available for MSYS) to
> transform absolute path names to the drive-letter form. The result
> works on MinGW/MSYS/wine for the first time!
>
> Here are the diff summary results on that platform.
>
> tcl
> Missing examples : 33
> Differing postscript output : 04 17 18 24 26 29
> Missing stdout :
> Differing stdout :
>
>
> The 33, 04, 18, and 26 differences also occur on Linux and I presume
> they are all due to the remaining plstring, plstring3, and pllegend
> propagation issues to the Tcl examples (and possibly propagation
> issues to the Tcl bindings for pllegend).
>
> That leaves the differences for examples 17, 24, and 29 that occur
> on 32-bit wine, but not 64-bit Linux to investigate.
>
> diff reveals many example 17 differences between Tcl and C, but I
> cannot see any visual differences in the final results viewed
> with gv.
>
> diff reveals only ~30 or so lines of example 24 differences between Tcl and
> C, but there are obvious visual differences (extra characters in the Tcl
> version) in the results viewed with gv.
>
> ndiff --abserr 2 shows only two numerical differences for example 29
> between Tcl and C that are larger than 2 in the last place, but those
> two were quite large. gv showed small visual differences for the plot
> of the time discontinuities for pages 5 and 6 that presumably reflect
> those two large differences in the ndiff results. I ascribe this
> issue to rounding errors in the exact x position of the
> discontinuties. The problem will likely disappear if we move the
> discontinuties slightly away from page centre.
>
> In sum, probably example 17 and 24 need some more work on Tcl for
> 32-bit Windows platforms (and possibly 32-bit Linux platforms) while a
> change of all examples 29 to shift the discontinuties slightly from
> the exact centre of the plot will probably solve that (32-bit Tcl?)
> issue. Aside from these rendering issues it looks like everything
> works at least on my wine version of the Windows platform, and that
> good result needs confirmation on a Microsoft version of the Windows
> platform as well.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state implementation
> for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
> package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
> Linux Links project (loll.sf.net); and the Linux Brochure Project
> (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>
>
DISCLAIMER: This message is intended exclusively for the addressee(s) and may
contain confidential and privileged information. If you are not the intended
recipient please notify the sender immediately and destroy this message.
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The
Netherlands, Commercial Registration Number 41146461, is not liable in any way
whatsoever for consequences and/or damages resulting from the improper,
incomplete and untimely dispatch, receipt and/or content of this e-mail.
------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
