Hi Sheila,
> The latest ncdump rejects filenames starting with the digits 0,1 and 2.
> 3 - 9 are fine. This is a snag when file-naming conventions starting
> with year date have been adopted - is this intentional?
>
> In ncdump/dumplib.c there's a check on the leading character for the hex
> range 0x01 - 0x32; changing the upper limit to 2f resolves our immediate
> problems, but if that's what was intended we'll have the same problems
> in later releases. Also if that test turns up elsewhere that I haven't
> found yet.
Thanks for reporting the bug. It's fixed in the next daily snapshot
release, but the immediate one-line patch to ncdump/dumplib.c (for
either netCDF-4.0 or netCDF-3.6.3) is appended.
--Russ
Index: netcdf-3/ncdump/dumplib.c
diff -c netcdf-3/ncdump/dumplib.c:1.59 netcdf-3/ncdump/dumplib.c:1.62
*** netcdf-3/ncdump/dumplib.c:1.59 Tue Jun 10 14:32:43 2008
--- netcdf-3/ncdump/dumplib.c Wed Jul 2 08:23:05 2008
***************
*** 1763,1769 ****
/* For some reason, and on some machines (e.g. tweety)
utf8 characters such as \343 are considered control character. */
/* if(*cp && (isspace(*cp) | iscntrl(*cp)))*/
! if((*cp >= 0x01 && *cp <= 0x32) || (*cp == 0x7f))
{
error("name begins with space or control-character: %c",*cp);
}
--- 1770,1776 ----
/* For some reason, and on some machines (e.g. tweety)
utf8 characters such as \343 are considered control character. */
/* if(*cp && (isspace(*cp) | iscntrl(*cp)))*/
! if((*cp >= 0x00 && *cp <= 0x20) || (*cp == 0x7f))
{
error("name begins with space or control-character: %c",*cp);
}
