tar file completion not working as expected under various option combinations

[dahart]

Describe the bug

Filename completion isn't working with tar in some cases where I expect it to work.

When extracting from an archive with tar's "traditional" option style (block of option letters with a dash), filename completion only works when 'f' is the last option letter in the options block, even though tar does not require the f argument to be last (see the tar man page for an example). I usually type something like "tar -xfvz file..." from muscle memory. This has been bugging me for years and I only just realized what's going on by trying all 24 letter permutations and mapping which ones work. :P Would it be relatively easy to allow "tar -xfvz ar" to complete filenames? In this case, completion is empty, so a fallback question might be can filenames be completed by default when there is no other completion?

I see the comment in completions/tar about advising to use a dash before the option block, but it would be extra nice if tar completion worked with the no-dash option block too. After all, tar supports the no-dash style and does not advise against it's use. Are there technical limitations?

When creating an archive, it seems filename completion of the archive with an existing name doesn't work even when the 'f' option is last or is given in GNU long-style. One reason to support this is when intentionally overwriting an archive. (It's not uncommon for me to have to create an archive several times before I get it right.) Another reason is when working on multiple tar files with a common prefix. A third, perhaps, is just to see that completion is working. Is the reason to disallow filename completion of the archive for safety? Are there other reasons not to complete existing filenames when creating an archive?

To reproduce

touch archive.tar
touch archive.tgz
tar -xfv ar<TAB> (nothing happens. Expect completion with archive.{tar,tgz} or archive.tar)
tar -xfvz ar<TAB> (nothing happens. Expect completion with archive.{tar,tgz} or archive.tgz)
tar -cfv ar<TAB> (nothing happens. Expect completion with archive.{tar,tgz} or archive.tar)

Would love if no-dash traditional options were also supported:
tar xfvz ar<TAB> (nothing happens. Expect same completion as tar -xvzf ar<TAB>)
tar cfvz ar<TAB> (nothing happens. Expect same completion as tar -cvzf ar<TAB>)
tar cfvz archive.tgz <TAB> (Completes directories only. Expect completion of files and directories, should be same behavior as tar -cfvz archive.tgz <TAB>)

Versions (please complete the following information)

- [ ] Operating system name/distribution and version: Linux 5.15.0-105-generic #115~20.04.1-Ubuntu SMP Mon Apr 15 17:33:04 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
- [ ] bash version, `echo "$BASH_VERSION"`: 5.0.17(1)-release
- [ ] bash-completion version, `(IFS=.; echo "${BASH_COMPLETION_VERSINFO[*]}")`: 2.14.0

Debug trace

tar-completion.log

[akinomyoga]

When extracting from an archive with tar's "traditional" option style (block of option letters with a dash), filename completion only works when 'f' is the last option letter in the options block,

This seems to be intentional according to the code comments in our tar completion.

bash-completion/completions/tar

Lines 6 to 16 in 8304d33

	# The "old" style arguments
	# -------------------------
	#
	# We don't "advice" the old tar option format by default for GNU tar, example:
	#
	# 'tar czfT /tmp/archive.tar patterns.txt'
	#
	# We rather advice the 'tar -czf /tmp/archive.tar -T patterns.txt' format of
	# arguments. Though, if user starts the 'first' tar argument without leading
	# dash, we treat the command line appropriately.
	#

Bash-completion had been advising users not to specify the arguments in that way.

[dahart]

Yes, as I mentioned in the report, I have seen bash-completion's 'advice', but it certainly would be very nice if tar's "traditional" argument style was supported. The comment you quoted does claim "if user starts the 'first' tar argument without leading dash, we treat the command line appropriately." Is that not implying that the "traditional" argument style is supported? The repro cases I provided do give the traditional options as the first argument to tar, and it doesn't seem like the command line is being handled as advertised. BTW, I didn't see this comment buried in the source until recently, so I guess most people who bump into this never see the advice, and just believe that bash-completion is broken when it comes to tar.

In any case, there is a bug where with the "unix-style" argument format currently requiring the 'f' to be last, right?

Out of curiosity, why is bash completion opinionated about tar's supported argument styles in the first place? Is there a technical reason why it's difficult, is this something bash-completion's design can't do very well? If there isn't a strong technical reason, humor me for a moment, here are some reasons it would be nice to drop the 'advice' and support tar's traditional argument style. The "traditional" style is the smallest / fastest-to-type, and the longest supported argument style for tar; tar is not deprecating the "traditional" argument style, it's a valid, supported, and ongoing alternative according to tar's documentation; the "traditional" style is the first one described in the man page; and the advice is asking users to change ingrained habits.