Aside, neither the implementation here or the one in _comp_cmd_sudo takes the possible sudo/doas -u argument into account but blindly assumes root. That we can address in a followup PR if we like sometime, but that'd needs some work -- neither current user nor root allowances are the right thing to do is -u sets something else beside root or the current user.
Originally posted by @scop in #766 (comment)
Maybe we could add a test case or few for the transitive allowed_users/groups sudo/doas behavior. Would go nicely with if we want to implement the -u awareness as in above though.
Originally posted by @scop in #766 (comment)
This needs the modifications at two sides, the sudo/doas side (recording the user/group information similarly to the existing line local _comp_root_command=$1) and the _comp_compgen_allowed_{users,groups} side (branching the generation based on the recorded user/group). I think -g <group> may also affect the list of the users or groups as well as -u <user>.
Originally posted by @scop in #766 (comment)
Originally posted by @scop in #766 (comment)
This needs the modifications at two sides, the
sudo/doasside (recording the user/group information similarly to the existing linelocal _comp_root_command=$1) and the_comp_compgen_allowed_{users,groups}side (branching the generation based on the recorded user/group). I think-g <group>may also affect the list of the users or groups as well as-u <user>.