This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Hi Robert, You can make a simple local modification to the netCDF-3 library source to allow arbitrary characters in names. Just change the NC_check_name() function in libsrc/string.c to not check the characters in names by removing the for loop in that function. Everything should still compile and link fine, but if you run "make check" there will be some failed tests corresponding to checking that illegal characters in names get an error return. This will give you an up-to-date version of netCDF-3 that doesn't enforce name checks, but won't solve the problems with IDL, unless IDL links dynamically to the netCDF library. If IDL has a statically linked version of the library, I think all you can do is request the IDL vendor (ITT?) to make a version that links dynamically to netCDF, or make a version that links statically to your custom netCDF library, or get the IDL source so you can do this yourself. Any of these alternatives be impractical or expensive. If you continue to create netCDF files with spaces in variable names, there may be other netCDF applications and utilities that will have problems with these files. For example, the ncgen utility will not work properly with a variable name that comtains spaces, because the grammar for CDL (the text notation for netCDF data supported by ncdump and ncgen) requires constraints on names for variables, dimensions, and attributes. Because of potential problems like this, we will not distribute an alternate version of netCDF-3 that does not enforce naming conventions, but it's easy for you to create such a version, as described above. NetCDF-4 permits Unicode names that are UTF-8 encoded, and it's possible that will require removing some naming constraints, but that is currently unexplored (and untested) territory. A beta-test version of netCDF-4 is available, if you want to test it. Sorry about the problems caused by not enforcing the name constraints in version 2.4, but that's now a very old and unsupported version ... --Russ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: QMC-939658 Department: Support netCDF Priority: Normal Status: Closed