Jeff King <peff@xxxxxxxx> writes: > On Mon, Jan 27, 2020 at 11:59:03AM -0500, Eric Sunshine wrote: > >> Second, this doesn't give any indication about how the lines should be >> terminated. It should instead be written as: >> >> set SP <key> NUL <value> NUL >> unset SP <key> NUL >> >> Third, importantly, unlike git-update-ref from which this DSL takes >> inspiration and in which "refs" might have oddball names for which >> NUL-termination makes sense, it's hard to imagine a case in which a >> configuration key would be so strange as to warrant NUL-termination. >> This observation suggests a simpler DSL in which only <value> is >> NUL-terminated: >> >> set SP <key> SP <value> NUL >> unset SP <key> LF >> >> (The proposed code changes in config.c would need adjustment, as well, >> to implement this revised DSL.) > > The section and key parts of a config key are pretty restricted, but the > subsection portion can contain anything except newline and NUL. So in > particular, it would be valid to have a space, which would make the > input ambiguous. > > I agree it would probably be rare, but isn't the whole point of "-z" to > be able to represent anything without worrying about quoting? Yup. I was tempted to say, in addition to "without worrying about quoting", "without worrying about the syntax". But unfortunately that would not work. If we were to add a new "frotz" subcommand in a future version of Git that takes N args, frotz SP <arg1> NUL <arg2> NUL ... <argN> NUL may how you'd express it, and it would be wonderful if the current version of Git that does not know "frotz" subcommand can at least parse and ignore it. That cannot however be done, though, because there is no syntactic difference between the argument terminator (after each arg) and subcommand terminator (after each subcommand).
