Hello Paul, thanks for your comment! > Something like that looks reasonable. > One major comment, though, is that the output of > tar should be parsable, i.e., it should be possible > to look at the output, figure out what format it is, > and parse it reliably. The current format doesn't have > that property, but these extended formats ought to, no?
I'm not sure if I follow you correctly -- you mean some 'universal' parser that gets tar's -t output and parses it alway correctly and gets as much info as possible? IIUC -- In previous proposal it is not so easy to achieve this goal in case that there is the 'vv' (not 'vvv') output requested. There may occur some ambiguity between --xattrs lines and --acls "added" lines, yes? But it is about mentioned compromise. I hope that usual programmer of usual tar parser knows which output he has. Disturbing usual user with additional bytes (that clearly differentiate kind of informations) may be here quite cumbersome (when you have 'vvv' output that may always be used). But it is just from my point of view because we were trying to make the output as much non-spamming as possible. One possibility how to make the brave parser's coder life easier is to turn on the 'vvv' header in 'vv' output and drop 'vvv' completely (that makes sense because the tar's interface will be little bit less complicated) or .. .. other possibility is to add two bytes -- 'CHARACTER COLON' before each additional line. Extended attributes e.g. "x:" for --xattrs, "a:" for --acls and "s:" for security context. Again -- the 'vvv' is not needed now and even its header can go out. Or .. .. do you (or other listener of this channel) see even other better solution? > A nit: in your proposal the tar -tvvvf output didn't have the > trailing "." or "+" that the tar -tvvf output did -- was > that a typo, or if not then what's going on? Yes of course -- I copied and pasted bad lines -- it was typo. Pavel
