-
Notifications
You must be signed in to change notification settings - Fork 400
-
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
Beta Was this translation helpful? Give feedback.
All reactions
Replies: 2 comments 7 replies
-
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.
Beta Was this translation helpful? Give feedback.
All reactions
-
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
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.
Beta Was this translation helpful? Give feedback.
All reactions
-
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.
Beta Was this translation helpful? Give feedback.
All reactions
-
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).
Beta Was this translation helpful? Give feedback.
All reactions
-
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.
Beta Was this translation helpful? Give feedback.
All reactions
-
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 ....
Beta Was this translation helpful? Give feedback.
All reactions
-
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.
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1
-
#965 has first baby steps to get a taste of this.
Beta Was this translation helpful? Give feedback.