Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #14868 > unrolled thread

Re: bash-5.0-beta2 breaks ``complete -D''

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: bash-5.0-beta2 breaks ``complete -D'' Tom Ryder <tom@sanctum.geek.nz> - 2018-11-30 22:33 +1300

#14868 — Re: bash-5.0-beta2 breaks ``complete -D''

[Multipart message — attachments visible in raw view] — view raw

On Fri, Nov 30, 2018 at 05:21:32PM +0800, Clark Wang wrote:
>Just tried 5.0-beta2 and it broke my completion rules. It can be 
>reproduced with the following steps: ...

Hello Clark; I noticed the same thing; I addressed it in an earlier 
message with the attached patch as a suggested fix, modifying a patch 
from Luca Boccassi.

<https://lists.gnu.org/archive/html/bug-bash/2018-11/msg00097.html>

----- Forwarded message from Tom Ryder <tom@sanctum.geek.nz> -----

Date: Sun, 25 Nov 2018 23:04:18 +1300
From: Tom Ryder <tom@sanctum.geek.nz>
To: Luca Boccassi <bluca@debian.org>
Cc: bug-bash@gnu.org
Subject: Re: [PATCH] Fix custom program's completions when initial word is set

On Fri, Nov 23, 2018 at 12:48:54PM +0000, Luca Boccassi wrote:
> The fix is to only override foundcs if both iw_compspec is not null
> and we are not in command position.

Thank you for this patch. I first ran into the issue with 5.0-beta2 another
way: I noticed that my default completion spec with -D as suggested by the
Bash manual page was no longer working:

   _completion_loader()
   {
        . "/etc/bash_completion.d/$1.sh" >/dev/null 2>&1 && return 124
   }
   complete -D -F _completion_loader -o bashdefault -o default

In 5.0-beta2, after running this code, for any command with no completion
specs defined in /etc/bash_completion.d, completing an argument does nothing.

Your second patch does not correct that, but it looks like that's because a
non-zero `foundcs` is coerced to 1 in it, when there are other meaningful
values for the integer as the first parameter for
`pcomp_set_readline_variables(int, int)`.

The attached patch is my own attempt, which seems to correct my issues as well
as the one you raised in this post. Long-time user, first-time poster...

----- End forwarded message -----

-- 
Tom Ryder <https://sanctum.geek.nz/>

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web