Description of problem: An example of a dashless (BSD?!) style tar command is: $ tar xf somefile.tar.bz2 as opposed to: $ tar --extract -f somefile.tar.bz2 Version-Release number of selected component (if applicable): 2.1-3 How reproducible: always Steps to Reproduce: 1. Go to a directory where you have a tar file (e.g. archive.tar.gz) and other non tar files (e.g. face.png) 2. Type the following at the shell prompt and press <tab> twice: (a)$ tar xzf <tab><tab> (b)$ tar xf archive.tar.gz <tab><tab> (c)$ tar uf archive.tar.gz <tab><tab> (d)$ tar -x -z -f <tab><tab> (e)$ tar -x -f archive.tar.gz <tab><tab> (f)$ tar --update -f deleteme.tar <tab><tab> Actual results: (a) only list of dirs and archives that end with tar.gz (b) list of files inside the tar archive (c) list of files inside the tar archive (d) all the files in cwd (e) all the files in cwd (f) bash gets stuck until ctrl+c is pressed Expected results: (a) and (d), (b) and (e), (c) and (f) should behave the same but they clearly do not. Additional info: Notice example (f): the bash is stuck and it gives the impression that some processing is going on, while in reality tar is waiting for input (due to mishandling of input), making the user waiting for no reason.
Created attachment 805447 [details] patch to fix the issue I re-wrote most of tar completion script and it now handles all types of cmd line options (ie single/double dash and dashless).
I have also reported this issue upstream at http://alioth.debian.org/tracker/index.php?func=detail&aid=314457&group_id=100114&atid=413095
Closing UPSTREAM as this is not Fedora specific and it's already in upstream BTS.