(During that discussion in 2017, I didn't realize that struct tapemetadata stored char ** argv; I assumed that it constructed a space-separated string upon archive creation and stored that.)
This PR has an unusual way of unambigiously representing argv: using multiple null characters.
tarsnap --list-archives --null behaves as expected; there's one null between each archive name:
NB: in the above example, xxd represents 0x00 with a . but all of my archives were created with the ./tarsnap binary. So if you look at the ascii representation, at first glance it might appear that there's 3 nulls before the command-line begins, but the hex confirms that it's the desired two 0x00 followed by a 0x2e.
I do not expect that --list-archives --null -v -v would be useful to any end users; it's only intended for programmers working on a gui or cli for tarsnap.
Requested in #294.
(During that discussion in 2017, I didn't realize that
struct tapemetadata
storedchar ** argv
; I assumed that it constructed a space-separated string upon archive creation and stored that.)This PR has an unusual way of unambigiously representing
argv
: using multiple null characters.tarsnap --list-archives --null
behaves as expected; there's one null between each archive name:-v
, then there's two null characters between each field:-v -v
options, then there's three null characters separating each item in theargv
list:NB: in the above example,
xxd
represents0x00
with a.
but all of my archives were created with the./tarsnap
binary. So if you look at the ascii representation, at first glance it might appear that there's 3 nulls before the command-line begins, but the hex confirms that it's the desired two0x00
followed by a0x2e
.I do not expect that
--list-archives --null -v -v
would be useful to any end users; it's only intended for programmers working on a gui or cli for tarsnap.