On Wed, Aug 05, 2009 at 03:29:19PM -0400, J. Bruce Fields wrote: > On Wed, Aug 05, 2009 at 03:14:11PM -0400, Steve Dickson wrote: > > After thinking about this.. I've convinced myself that the internal > > parsing routines should make the Section names case-insensitive > > but the rest of the data (i.e the tag, value) should be returned as is > > and let the callers deal with the case... > > > > The reason being everything hangs off Section names. So making those > > easier to find I think is a good thing and hopefully it will make > > managing config files a bit less error prone.... > > That's probably not what I would do, but I could live with that, as long > as we're preserving the case of paths and user/group names. > > By the way, it looks like the git code to handle their extended section > names (the [key "string"] thing) is in git's > config.c:get_extended_base_var(), if that's a useful example. (And, by the way, they agree with you on case-sensitivity: from the git-config man page: "The file consists of sections and variables. A section begins with the name of the section in square brackets and continues until the next section begins. Section names are not case sensitive. Only alphanumeric characters, - and . are allowed in section names. Each variable must belong to some section, which means that there must be section header before first setting of a variable. "Sections can be further divided into subsections. To begin a subsection put its name in double quotes, separated by space from the section name, in the section header, like in example below: [section "subsection"] "Subsection names can contain any characters except newline (doublequote " and backslash have to be escaped as \" and \\, respectively) and are case sensitive. Section header cannot span multiple lines." ) --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
