(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 tapemetadatastoredchar ** 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 --nullbehaves as expected; there's one null between each archive name:-v, then there's two null characters between each field:-v -voptions, then there's three null characters separating each item in theargvlist:NB: in the above example,
xxdrepresents0x00with a.but all of my archives were created with the./tarsnapbinary. 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 two0x00followed by a0x2e.I do not expect that
--list-archives --null -v -vwould be useful to any end users; it's only intended for programmers working on a gui or cli for tarsnap.