Convention for indicating "main" command for xfunc and utility functions

[scop]

Invoking a utility or a xfunc function often involves executing a "main" command. Some functions take it as the first positional parameter, some take it as the last, and some just hardcode one. For example the functions in completions/ssh, many xfunc functions throughout, etc.

I suggest we make this consistent. Positional parameters are inflexible and somewhat ugly for this, so I'm proposing we use a variable to indicate it. Perhaps a consistently named one for this one purpose would be handy.

So for example, let's say $xcmd (for both xfunc and utility, never mind the x):

_comp_xfunc_ssh_query()
{
    "${xcmd:-ssh}" -Q "$1" 2>/dev/null
}

...and calling it:

_comp_xfunc_ssh_query foo          # xcmd not specified, fallback activated
xcmd=$1 _comp_xfunc_ssh_query foo  # specific command (often with path) to invoke specified

[akinomyoga]

If we actually want to pass $1 of the original command, it is already saved in comp_args[0] with the new _comp_initialize fc4af85. But then, when we want to specify a different command than the original $1, we need a mechanism to specify it like this suggestion.

[scop]

Good point re comp_args.

The only kind of a case I have in mind where we want to specify the command that is not the original $1 is in _comp_cmd_rpmbuild, where we are passing rpm from the same path as the rpmbuild being invoked if it exists:

bash-completion/completions/rpm

Lines 247 to 248 in 72a8c48

	local rpm="${1%build*}"
	[[ $rpm == "$1" ]] || ! type "$rpm" &>/dev/null && rpm=

(and there are some other things in the tree that would probably be better doing this, too, for example ssh things called from scp).

I suppose this case could be handled by locally setting $PATH with the dir rpmbuild resides in prepended to it and just invoke rpm without a path there. But then I we'd need some way to specify we do not want to invoke the original $1 for this case... and in other cases we do want to invoke the comp_args[0] command. Hm.

[scop]

External xfunc callers should not generally indicate the command though, because that would be making assumptions about the xfunc's internal implementation details. Passing the command to invoke would be generally something only callers in the same file whould do.

[akinomyoga]

If the external callers might also want to specify the command in some cases, we might finally need to use options like _comp_xfunc ssh query [-x xcmd] args. Or, _comp_xfunc [-x xcmd] ssh query args (inspired by _comp_compgen).

[scop]

It seems to me this issue boils down to having both internal and external callers for xfuncs. It does not matter that much how internal utility functions handle it, although it would be nice to have them and xfuncs consistent.

Making a -x xcmd option feels a bit much to me, and for xfuncs it would also feel like it was meant to be used by anything, whereas it really is there only for internal xfunc callers.

[akinomyoga]

Hmm, if the difference of the two interfaces with/without xcmd is purely coming from the difference for the internal vs external callers, another option might to be to prepare two functions, _comp_cmd_ssh_query xcmd ... and _comp_xfunc_ssh_query ..., where latter internally calls _comp_cmd_ssh_query default_xcmd ....

[scop]

Ah yes, this sounds like a winner. The internal one should be called e.g. _comp_cmd_ssh__query though. I'll have a look at implementing this.

[scop]

#965 has first baby steps to get a taste of this.