Re: repeated request about problem with []() in 3.5 version

>To: address@hidden
>From: Reimar Bauer <address@hidden>
>Subject: Re: 20020328: repeated request about problem with []() in 3.5 version
>Organization: Institut fuer Stratosphaerische Chemie (ICG-I)
>Keywords: CDL names, variable names, special characters

Hi Reimar,

> Re: problem with []() in 3.4 version
>   In-Reply-To: 
>   Your message of "Thu, 09 Apr 1998 15:49:26 +0200."
> <address@hidden>
> 
> In 1998 we talked about ()[] and @ in short_names because you did 
> a global change to varnames to use only alphanumeric keys and _.
> You did this change because of the ascii read write routine
> which got a conflict by some signs.
> Our chemistry model output files have a lot of these signs and we
> do like to use these signs in all netCDF Versions.
> 
> You developed for us a fix for the 3.4 version. 
> 
> Please give us this fix for the 3.5 version which is
> described in
> 
> http://www.unidata.ucar.edu/packages/netcdf/known_problems_34.html#name-restrictions
> 
> too.

I just checked and the netCDF 3.4 patch still works for netCDF version
3.5.0 if you apply it from the netcdf-3.5.0/src/ directory:

  tmp/netcdf-3.5.0/src$ /opt/gnu/bin/patch < ~/www/netcdf/patch-3.4-names 
  Hmm...  Looks like a new-style context diff to me...
  The text leading up to this was:
  --------------------------
  |Patch for netcdf-3.4/src to remove restrictive name checking
  |==================================
  |This patch is for the 3 files 
  |
  |    libsrc/string.c
  |    nc_test/test_write.c
  |    nf_test/test_write.F
  |
  |It removes the current checking for valid characters in names of
  |variables, dimensions, and attributes, to make sure such names are
  |consistent with the CDL name restrictions that permit only alphanumeric
  |characters and `_', `-', and `.' in names.  If you apply this patch, you
  |will be able to create netCDF files for which the ncgen utility will no
  |longer work on the CDL output from ncdump.
  |
  |To apply, invoke the following command from the netcdf-3.4/src/
  |directory, where you should replace PATCHFILE by the name for this file:
  |
  |  patch  < PATCHFILE
  |
  |Then rebuild with "make all".  Test with "make test".  Install with
  |"make install".
  |
  |Index: libsrc/string.c
  |===================================================================
  |RCS file: /upc/share/CVS/netcdf-3/libsrc/string.c,v
  |retrieving revision 1.57
  |diff -c -r1.57 string.c
  |*** 1.57     1997/09/02 18:27:32
  |--- string.c 1998/04/28 22:24:15
  --------------------------
  Patching file libsrc/string.c using Plan A...
  Hunk #1 succeeded at 28.
  Hmm...  The next patch looks like a new-style context diff to me...
  The text leading up to this was:
  --------------------------
  |Index: nc_test/test_write.c
  |===================================================================
  |RCS file: /upc/share/CVS/netcdf-3/nc_test/test_write.c,v
  |retrieving revision 1.19
  |diff -c -r1.19 test_write.c
  |*** 1.19     1997/10/17 18:21:44
  |--- test_write.c     1998/04/28 22:26:12
  --------------------------
  Patching file nc_test/test_write.c using Plan A...
  Hunk #1 succeeded at 461.
  Hunk #2 succeeded at 587.
  Hunk #3 succeeded at 1267.
  Hmm...  The next patch looks like a new-style context diff to me...
  The text leading up to this was:
  --------------------------
  |Index: nf_test/test_write.F
  |===================================================================
  |RCS file: /upc/share/CVS/netcdf-3/nf_test/test_write.F,v
  |retrieving revision 1.7
  |diff -c -r1.7 test_write.F
  |*** 1.7      1997/06/11 19:38:01
  |--- test_write.F     1998/04/28 22:27:30
  --------------------------
  Patching file nf_test/test_write.F using Plan A...
  Hunk #1 succeeded at 453.
  Hunk #2 succeeded at 579.
  done

After this, I just did the usual "./configure; make all test" and
everything seemed to build and test OK.  I've added an entry
for this to the "Known Problems with the netCDF 3.5.0 Distribution"
page pointing to the netcdf-3.4-names patch.

> Later on we have discussed to use some kind of masquerading for
> signs which are complicated by the ascii files. I thougt that' you
> agree to this idea.

I found an email from 19 Sep, 1999, with this exchange:

  http://www.unidata.ucar.edu/cgi-bin/mfs/70/3559

I have a vague recollection of further discussion on this, but can't
seem to find it.

Now that I think about it, it seems to me that the real problem with
modifying the general netCDF distribution to permit other special
characters in names is that datasets containing such names would break
other interfaces built on top of netCDF that we have no control over.
For example, I suspect that there might be difficulties with accessing
variables with parentheses or brackets in their names from the DODS,
IDL, MATLAB, Python, Perl, or Ruby interfaces.

--Russ