On Sun, 11 Apr 2010 00:56:47 +1000, Jon Seymour <jon.seymour@xxxxxxxxx> wrote: > On Sat, Apr 10, 2010 at 11:35 PM, Julian Phillips > <julian@xxxxxxxxxxxxxxxxx> wrote: >> On Sat, 10 Apr 2010 00:09:59 -0400, Jeff King <peff@xxxxxxxx> wrote: >>> Your parser is already broken if you are calling split, as the filenames >>> may contain spaces (and will be quoted in that case, and you need to >>> unmangle). You should use "-z". >>> >>> You will probably then realize that the "-z" format looks like: >>> >>> XY file1\0file2\0 >>> >>> which still sucks. It would be more friendly as: >>> >>> XY\0file1\0file2\0 >>> >>> So you could split on "\0". But even with that, you can't just blindly >>> split, as the column and record separators are the same, and you might >>> have one or two filenames. >> >> Not true. If the second form was used, then you _can_ split on \0. It >> will tokenise the data for you, and then you consume ether two or three >> tokens depending on the status flags. So it would make the parsing >> simpler. But to make it even easier, how about adding a -Z that makes >> the >> output format "XY\0file1\0[file2]\0" (i.e. always three tokens per >> record, >> with the third token being empty if there is no second filename)? >> Though >> if future expandability was wanted you could end each record with \0\0 >> and >> then parsing would be a two stages of split on \0\0 for records and then >> split on \0 for entries? > > Surely that won't work - if file2 can be empty, \0[file2]\0 reduces to > \0\0 which would be confused with the \0\0 proposed as a record > separator. Yes. But they were alternative suggestions, so if using \0\0 as the record marker you would omit the second filename when empty as is currently done. -- Julian -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html