On 2026-02-02 07:06, Pavel Cahyna wrote:
On Fri, Jan 30, 2026 at 12:58:28PM -0800, Paul Eggert wrote:
By the way, what should '--one-top-level=' (with an empty DIR) do? The
documentation is unclear. An empty DIR is not a relative file name....
No idea. Shouldn't it be equivalent to just '--one-top-level' ?
No, for the same reason '--occurrence=' is not the same as
'--occurrence'. So to finish my thought, '--one-top-level=' should be
invalid, because the empty string is not a valid file name.
I am leery of mkdir -p semantics in general, as it has too many
issues (what permissions should the intermediate directories use?).
Could they use the same permissions as the last one?
Well, retreating a bit, I suppose we could do the same thing that we
already do with long file names none of whose components already exist.
4. We do (2) and (3) lazily, i.e., only when we need FOO/DIR (or DIR) open
to extract a file underneath it.
Is it necessary? I would assume that it is simpler to do it
unconditionally at the beginning, and that we need it almost always
anyway.
I am worried about combinations like '-C a -C b file', where we should
create b/DIR (for b/DIR/file) but need not create a/DIR.
Hmm. Is there a a way to know which -C before the extraction starts is
the last one? (Or, when we have processed the last -C before the
extraction starts? And do (2) and (3) at this moment?)
Yes, that's what I meant by "lazily". The idea is to do what 'tar' does
now, and one must be lazy to do that.
https://github.com/skupperproject/skupper-router/commit/6a9f03f590a1ab44e106b3af63a9fa0f0fbdef30
They remarked that according to a search on GitHub (I had not thought
of that) they are hardly alone. When I search on GitHub for
"--one-top-level", most of the uses are with a relative path, but I saw
some cases with an absolute path.
I suppose we need to support that, then. But how does --one-top-level
interact with -P? Without -P, shouldn't --one-top-level=/a/b/c be
equivalent to --one-top-level=a/b/c? (This whole thing is confusing, if
you ask me, and we need to be clear in the documentation about the
confusion.)
Just to make it clear, I suppose you mean to sacrifice compatibility in
the second case (--show-transformed output) but not in the first
(transformation of file names to remove the prefix if needed), right?
That was what I meant, yes. But perhaps we should be more conservative
about the user-visible changes.
+If multiple @option{-C} options are present,
+each has its own subdirectory with the same name.
What does this mean? I tried mkdir -p a/b; tar -C a -C b --one-top-level=foo
-xf ...tgz
and it did not create a/foo and a/b/foo, just a/b/foo.
Something like this:
tar --one-top-level=foo -C a xxx -C b yyy -xf tarball
This extracts a/foo/xxx and a/b/foo/yyy.
Note the "When this option is used during archive creation" - this seems
to imply that you should not use -C in the middle of arguments during
extraction to change directory after some files are extracted, although
in practice this works (is it the same case like --one-top-level with an
absolute path?)
It's long been the case that -C a -C b is equivalent to -C a/b, and that
if there's something between the -C options it's extracted into a.
