Re: completion utility functions that take options generally do not work

On Wed, Jun 3, 2026 at 6:01 PM Oliver Kiddle <[email protected]> wrote:
>
> This is a change I've used privately for a while and Mikael's recent
> post about utility functions taking compadd options reminded me.

Thanks for mentioning that, it reminded me that I intended to reply here.

On Mon, May 25, 2026 at 1:52 AM Mikael Magnusson <[email protected]> wrote:
>
> When you call a utility function from _arguments, like this (this is a
> bad example, it's only used on IRIX):
>       '-b[mount all filesystems in /etc/fstab except those
> listed]:mount point:_dir_list -s,'
> _arguments helpfully adds some compadd options to the argument list
> for you to pass on to compadd "$@". However, it adds these between the
> first word and the rest of the words, so the resulting command would
> be something like _dir_list -J mygroup -1 -s or so.
[...]
> If you add a space after the colon in your _arguments spec, then it
> will not add the compadd options, and the argument parsing in the
> utility function will work. But since it doesn't add the compadd
> options, the compadd calls will obviously pass on an empty "$@", this
> would also not be great, plus we'll never get anyone to remember to
> add this space.
>
> I'm not sure if there's an obvious solution here, unfortunately.

It would mean a small amount of rewriting in each of a number of
functions, but could we eliminate the the literal compadd "$@"
practice entirely and instead pass the compadd arguments around in a
"localized global" array, after the manner of curcontext?  _arguments
does that kind of thing already when supplying "$expl[@]".

For the utilities that already work mostly correctly, it would (I
think) primarily be a matter of adding
   local -a compaddargs=( "$compaddargs[@]" )
and then after the utility's own arguments have been interpreted do
   set -- "$compaddargs[@]"
and thereafter compadd "$@" works as previously expected.

I haven't thoroughly reviewed the 113 files that might need this
editing, so perhaps there's a flaw in this approach.