FS#39142 - [bash-completion] bash file completion involving ~ fails

Attached to Project: Arch Linux
Opened by Peter Wu (Lekensteyn) - Tuesday, 04 March 2014, 10:51 GMT
Last edited by Bartłomiej Piotrowski (Barthalion) - Sunday, 12 June 2016, 09:31 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Eric Belanger (Snowman)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 7
Private No

Details

Description:
Since upgrading bash, tab completions involving ~ do not complete any files or directories.

Examples:
* ~<TAB> - properly suggests user names
* ~/<TAB> - only suggests directories, not file names
* ~peter/<TAB> - same as above
* ~/.ssh/<TAB> - *no* suggestions at all

This has a great impact on my productivity with bash, please withold from upgrading until this is sorted out.

Package versions:
bash 4.3-2 (testing)
bash-completion 2.1-2
This task depends upon

Closed by  Bartłomiej Piotrowski (Barthalion)
Sunday, 12 June 2016, 09:31 GMT
Reason for closing:  Fixed
Comment by Allan McRae (Allan) - Tuesday, 04 March 2014, 11:33 GMT
What has exactly changed here? I just tested those with bash-4.2 and bash-4.3 and it gave the exact same results. Both with and without bash-completion installed. These are also expected behaviour...
Comment by Peter Wu (Lekensteyn) - Tuesday, 04 March 2014, 14:24 GMT
How is it expected that files and directories are not completed (btw, there should be a command before those examples, e.g. `ls ~/.ssh/<TAB>`).

Downgrading to 4.2.045-5 and completion works fine.

This patch[1] solves the completion issue with ls, but vim still has issues.

I've made another workaround (see attached patch) that fixes the issue completely for me. This is very likely unacceptable for upstream bash-completion, but works for now.

[1]: http://lists.alioth.debian.org/pipermail/bash-completion-devel/2013-February/004740.html
   compl.patch (0.5 KiB)
Comment by Peter Wu (Lekensteyn) - Tuesday, 04 March 2014, 14:26 GMT
Oh, the cause is a behavior change of printf wrt quoting.

$ printf '%q\n' '~/.ssh/'
~/.ssh/ # in bash < 4.3
\~/.ssh/ # in bash >= 4.3
Comment by Allan McRae (Allan) - Tuesday, 04 March 2014, 23:23 GMT
Ah, with a command in front, then it is not expected...
Comment by pnewm (moetunes) - Wednesday, 05 March 2014, 01:19 GMT
Thought I'd mention more bash 4.3 fail in here...
Using <tab><tab> to list files in a directory with escaped characters in it's name doesn't work in 4.3 either.
e.g. ls ./this\ directory/<tab><tab> does nothing.
downgrading to 4.2 has things working like they always have.
Comment by Allan McRae (Allan) - Wednesday, 05 March 2014, 01:32 GMT
Reassigning - these are all bash-completion issues.
Comment by pnewm (moetunes) - Thursday, 06 March 2014, 09:59 GMT
This bug is marked "Waiting for response". Who are we waiting on a response from?
Comment by Peter Wu (Lekensteyn) - Thursday, 06 March 2014, 10:01 GMT
That flag was added in the initial comment, I replied in the post thereafter.
Comment by pnewm (moetunes) - Thursday, 06 March 2014, 10:34 GMT
Thanks for the quick reply.
I was under the impression since the bug had been assigned then reassigned it would now be marked "Assigned".
Don't know who would be responsible for that or if it is even relevant...
Comment by Anatol Pomozov (anatolik) - Friday, 07 March 2014, 00:20 GMT
Another weird autocompletion with bash from [testing]:

$<TAB> -bash: words: bad array subscript
$<TAB> -bash: words: bad array subscript
$<TAB> -bash: words: bad array subscript

$<TAB><TAB> -bash: words: bad array subscript
-bash: words: bad array subscript

pkg/ src/
Comment by Peter Wu (Lekensteyn) - Friday, 07 March 2014, 10:01 GMT
@Anatol That bad array error was present before the new Bash version although it only happened with:

$ <spaces><TAB>

e.g.

$ -bash: words: bad array subscript
-bash: words: bad array subscript

This is the possible troublesome path where cword becomes negative (in reverse order):
__reassemble_comp_words_by_ref
__get_cword_at_cursor_by_ref
_get_comp_words_by_ref
_init_completion

Display all 148 possibilities? (y or n)

OT: Ubuntu and Debian are also affected:
https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1288031

Tip: if you want to debug this, use `set -x` for more details (its inverse is `set +x`).
Comment by Bartłomiej Piotrowski (Barthalion) - Monday, 17 March 2014, 11:05 GMT
Please test bash-completion 2.1-3 from [testing].
Comment by Peter Wu (Lekensteyn) - Monday, 17 March 2014, 11:20 GMT
There is no 2.1-3 in testing yet,
I applied bash-4.3.patch from r208062 to /usr/share/bash-completion/bash_completion (after reverting my changes),
but the issue persists (unable to tab-complete ~/.ssh/).

I encountered another (related?) issue, file completion does not occur at all when no key words are given. For instance:
$ ls <TAB><TAB>
(completions shown, but without files such as .bashrc)
$ ls .<TAB><TAB>
(now files are included)
Comment by Gustavo Alvarez (sl1pkn07) - Monday, 17 March 2014, 18:26 GMT
ow, sorry, bad bugreport

greetings
Comment by Bartłomiej Piotrowski (Barthalion) - Monday, 17 March 2014, 19:22 GMT
Peter: I'm unable to reproduce the issue after installing 2.1-3. "ls <TAB><TAB>" completes available files and directories fine.
Comment by pnewm (moetunes) - Monday, 17 March 2014, 19:55 GMT
Upgrading to bash-completion 2.1-3 and bash 4.3 resolves the issue I brought up.
I can also list the files in .ssh/ with ~/.ssh/<tab><tab>.
Thanks.
Comment by Leonid Isaev (lisaev) - Friday, 21 March 2014, 16:21 GMT
  • Field changed: Percent Complete (100% → 0%)
bash-completion 2.1-3 fixes only some, but not all, issues.

Specifically, the completion of the type:
$ links $(<~/te<TAB>) doesn't work (it used to). Instead, I get
bash: unexpected EOF while looking for matching `)'
bash: syntax error: unexpected end of file, I think in _quote_readline_by_ref()

I can open a separate bug report, but perhaps it's better to keep completion-related regressions in one place.

Thanks.
Comment by Eric Belanger (Snowman) - Friday, 21 March 2014, 19:44 GMT
This should be reported upstream.
Comment by Bartłomiej Piotrowski (Barthalion) - Tuesday, 25 March 2014, 12:22 GMT
I've applied this[1] patch to bash, please test if these packages[2] fixes completion.

[1] https://lists.gnu.org/archive/html/bug-bash/2014-03/msg00123.html
[2] http://pkgbuild.com/~barthalion/tmp/fs39142/
Comment by Peter Wu (Lekensteyn) - Tuesday, 25 March 2014, 15:18 GMT
I've built 4.3-3 with that the pcomplete-dequote patch, tested with bash-completion 2.1-4 and completion still works.

What is this patch supposed to fix?
Comment by Leonid Isaev (lisaev) - Wednesday, 26 March 2014, 17:17 GMT
Thanks.

The above patch makes the error go away (so the length of the input string is calculated properly AFAIU), but the completion still doesn't work:
-----
$ pacman -Q bash bash-completion
bash 4.3-3.1
bash-completion 2.1-4
$ echo 1 > /tmp/1.pid
$ cat /tmp/1.pid
1
$ kill $(cat /tmp/<TAB>)
-----
... and the shell doesn't complete the filename.

I did not look in detail at what happens, but I'll do and report this upstream.
Comment by John Luebs (jkluebs) - Wednesday, 02 April 2014, 15:44 GMT
I notice this has not been mentioned:
https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1289597

I seem to be affected by it even in -4.
Comment by Rafael (RSFalcon7) - Tuesday, 22 April 2014, 15:23 GMT
Apparently this had been fixed in ubuntu (https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1289597), so I guess it is just a matter of updating the repo
Comment by Eric Belanger (Snowman) - Wednesday, 23 April 2014, 01:13 GMT
bash-completion-2.1-5 has the ubuntu patch. Does that fix the issue?
Comment by Rafael (RSFalcon7) - Wednesday, 23 April 2014, 15:21 GMT
"$<tab>" results in "$ bash: words: bad array subscript"
Comment by Samantha McVey (samcv) - Saturday, 11 June 2016, 04:33 GMT
Can somebody test this again on the latest version of bash? Ticket hasn't been updated in two years so would like to find the current status of whether this is or is not still occurring.
Comment by Peter Wu (Lekensteyn) - Sunday, 12 June 2016, 05:21 GMT
The original and follow up issue (with tabbing on an empty command) cannot be reproduced anymore here, it can be closed. Thanks!
Comment by Samantha McVey (samcv) - Sunday, 12 June 2016, 07:02 GMT
Awesome, thanks for the response. Will request this be closed.

Loading...