Implement --one-top-level

[dzwdz]

Closes #2354.

This also implements support for optional arguments in bsdtar, as splitting it into a separate PR wouldn't make sense.

I think it would be nice to have an additional option that aborts the extraction if the directory exists, but I haven't implemented that here (yet?). For me, the point of --one-top-level is not to mess with the files/directories I already have - so it's kinda annoying that, in this one specific case, tar will extract files into an existing directory anyways. Sadly, GNU tar made that mistake before us, so I had to copy it.

[sonarqubecloud]

Quality Gate passed

Issues
4 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[kientzle]

A couple of questions:

1. Should you be able to specify multiple such options? (--one-top-directory=foo --one-top-directory=bar)?
2. Should --one-top-level refuse to use a pre-existing directory? We don't necessarily have to mimic GNU tar in this respect if there's a compelling reason not to.
3. Should this be order-sensitive with respect to -C? E.g., should --one-top-level=foo -C=bar mean the same thing as -C=bar --one-top-level=foo? (In particular, if --one-top-level will use a pre-existing directory, then it's very similar to -C when the directory exists.)

[kientzle]

I'll also point out that there is a simple way to achieve this already:

mkdir foo && tar xvf foo.tar -C foo

Not every problem has to be solved within tar itself.

There is some merit in supporting GNU tar options when those options are widely used by shell scripts. I've not personally seen folks rely on --one-top-level, so I'm not yet convinced this meets that bar.

[DHowett]

I fear GNU may have missed an opportunity to improve tar; they could have designed "one-top-level" to act as mkdir foo && tar -x -C foo with an optional implicit --strip-components=1 if the archive seems like it needs it (ergo, if the archive already has one top level directory.)

Otherwise, why call it that? Extracting an archive that contains a single top-level directory using "one-top-level" will produce a single top-level directory containing a single directory.

That's just -C but worse in every way.

[DHowett]

Ah, it looks like @dzwdz had the same thought in #2882! :)

[dzwdz]

Should you be able to specify multiple such options?

I think this mostly makes sense in the context of alias tar="bsdtar --one-top-level, and then specifying the exact name with another --one-top-level argument, or passing something like -no-one-top-level (not implemented, also feels a bit silly) to disable it. GNU tar uses the last argument passed, it doesn't combine them like -C.

Our handling of --one-top-level=1 --one-top-level might be different, I haven't checked yet. Oh, and I think right now there's a memory leak if you pass --one-top-level=1 --one-top-level=2?

Should --one-top-level refuse to use a pre-existing directory? We don't necessarily have to mimic GNU tar in this respect if there's a compelling reason not to.

Yeah, that'd be a footgun if you switch from bsdtar to GNU tar. I could picture myself in a few years using --one-top-level with GNU tar, thinking that it has the same "safety" feature, and finding out that it doesn't the hard way.

Should this be order-sensitive with respect to -C?

That wouldn't make sense if not for the unfortunate detail for ignoring existing directories (logically you can't chdir into a subdirectory of a newly created dir), so no. GNU tar doesn't seem to care about the order relative to -C.

---

Not every problem has to be solved within tar itself.

I agree, I've dealt with this using some wrapper scripts up until now¹. I thought about writing my own extraction utility using libarchive too, but at this point I think it's better to just contribute the features I want to bsdtar, instead of having two libarchive-based extraction utilities with somewhat overlapping option sets.

---

That's just -C but worse in every way.

I mean, I think there's some merit to it. It's useful not to have to run mkdir separately, and the name inference is also nice.

Footnotes

1. Otherwise this gets really annoying for e.g. Bandcamp albums. mkdir 'SONIC DRAGOLGO - MY SWEET HONEY BUNNY' && tar xvf 'SONIC DRAGOLGO - MY SWEET HONEY BUNNY.zip' -C 'SONIC DRAGOLGO - MY SWEET HONEY BUNNY', using a random one I had laying around as an example. ↩