"tar tvf" and "tar xvf" do not autocomplete filenames since 2.2

[scop]

"tar tvf" and "tar xvf" do not autocomplete filenames since 2.2

[scop]

Works for me. Although I suppose it's kind of debatable if "t" should complete filenames in archives in the first place.

Need more info about your environment (which OS, which tar, which bash), and see also https://github.com/scop/bash-completion#troubleshooting

[rworkman]

This is Slackware -current (development leading to 14.2).
[rworkman@liberty ~]$ ls -1 /var/log/packages/{bash-,tar-}
/var/log/packages/bash-4.3.042-x86_64-1
/var/log/packages/bash-completion-2.2-noarch-1
/var/log/packages/tar-1.28-x86_64-1

For the sake of clarity, I don't care about completing filenames inside the archive - that's not what this is about. This is about completing the actual file name.

I just downgraded to bash-completion-2.1 and both "tar tvf" and "tar xvf" will tab-complete the name of the tarfile now.

[scop]

Thanks for the clarification. Something strange is going on; in my basic setup I cannot reproduce, and in another I can, but so far I don't know what makes the behavior different between them. We also have a test suite item for this, and it passes in Travis (the test suite is otherwise unstable, but the tar tests pass).

@praiskup, any ideas? The setup where I can reproduce this is current rawhide mock chroot, everywhere else it appears to work just fine for me.

[praiskup]

Not reproducible in fedora-rawhide-x86_64 mock chroot working in /tmp. Both
file name completion and tarball contents are completed fine. My native F23 is
fine too.

What are the contents of your working directory? My is:

<mock-chroot>sh-4.3# ls -alh
total 4.0K
drwxrwxrwt.  9 root root 200 Mar 16 07:08 .
dr-xr-xr-x. 18 root root 460 Mar 16 07:04 ..
drwxrwxr-x.  2 root root  40 Mar 16 07:03 ccache
drwxrwxrwt.  2 root root  40 Mar 16 07:04 .font-unix
drwxrwxrwt.  2 root root  40 Mar 16 07:04 .ICE-unix
drwxr-xr-x.  2 root root 100 Mar 16 07:06 testdir
-rw-r--r--.  1 root root 168 Mar 16 07:06 test.tar.gz
drwxrwxrwt.  2 root root  40 Mar 16 07:04 .Test-unix
drwxrwxrwt.  2 root root  40 Mar 16 07:04 .X11-unix
drwxrwxrwt.  2 root root  40 Mar 16 07:04 .XIM-unix

[praiskup]

Don't you use $TAR_OPTIONS?

[scop]

My working dir contents:

<mock-chroot>sh-4.3# ls -la
total 20
drwxrwxrwt  5 root      root      4096 Mar 16 10:42 .
dr-xr-xr-x 18 root      root      4096 Mar 15 19:35 ..
drwxrwsr-x 19 mockbuild      1000 4096 Mar  9 07:42 ccache
-rw-r--r--  1 root      root         0 Mar 15 19:45 foo.tar.bz2
-rw-r--r--  1 root      root         0 Mar 15 19:40 foo.tar.gz
drwxrwxr-x  3 root      root      4096 Mar 16 10:39 tmpjwNSev
drwxrwsr-x  3 root      mockbuild 4096 Mar  1 22:56 tmppc7lsyyt

$TAR_OPTIONS is not set. set -x debug output for attempted tar xvf <TAB> (which produces no completions) is in https://gist.github.com/scop/745c19fe9d1909a295e2 . Somehow it seems to end up trying to complete contents of a tarball that has not even been given as args. (This is with vanilla 2.2, the /tmp/jetel stuff has been cleaned up in master afterwards.)

[praiskup]

Your set -x output starts to differ from my on:
[[ -A, --catenate, --concatenate append tar files to an archive =~ ^[[:blank:]]{1,10}(((,[[:blank:]])?(--?([][a-zA-Z0-9?-=]+))(,[[:space:]])?)+).*$ ]]
My [[ command returns true and goes to than branch, your returns false.

[praiskup]

jetel stuff has been cleaned up in master afterwards

Sorry for this :(.

[praiskup]

This seems like the code is not able to parse tar --help on your box, because of wrong?
regexp. Can you better debug that? I am unable to reproduce.

+ rpm -q bash
bash-4.3.42-4.fc24.x86_64

[scop]

I've reduced the issue to this:

[[ -A =~ ^-[A?-=] ]] && echo hello

In my rawhide chroot, the regex does not match and this outputs nothing. On the F-23, CentOS, and Ubuntu boxes I tried, it matches and outputs hello. My rawhide chroot should be pretty much exactly the same as yours, so I have no idea why the behavior differs.

Anyway, I can think of a possible issue in that regex: maybe the ?-= gets treated as a character range from ? to =. At least changing it to ?=- produces consistent (matching) results in all setups I've tried.

I've pushed that change as 0b7189d; @rworkman, could you try out if making that change fixes it for you and report back?

[scop]

(BTW no matter whether ?-= gets treated as a character range or not, I think my reduced test case should have matched, because the explicit A is there anyway. Maybe it breaks the matching somehow else.)

[praiskup]

@scop, I would file a bug against Fedora's bash, but I'm not able to reproduce this.
Will you do this? FWIW, I run mock on native fedora-23-x86_64 box.

[rworkman]

Confirmed that 0b7189d fixes this; thanks much, guys! :-)

[scop]

Fedora bash bug report filed, https://bugzilla.redhat.com/show_bug.cgi?id=1318277

Thanks to both for help with debugging this!