bash-completion
bash-completion copied to clipboard
scop
Support for setfacl
Could not find an existing completion script for filesystem acl modification and I don't see any completion code in the upstream acl project. Adapted from chown. Understands but does not suggest short options.
I've marked this as draft for now because I wasn't sure how to best account for groups that contain colons (as _usergroup() does), or whether that could be a TODO given completion covering common use cases is better than none.
Hm, we should add a template for pull requests so that the request to ask upstream to include the completion first is more prominent. Anyway, for time being, see https://raw.githubusercontent.com/scop/bash-completion/master/.github/ISSUE_TEMPLATE/feature_request.md and the start of CONTRIBUTING.md.
I did hear back, but they never confirmed whether they even tried it, and said it had to be sent as a patch. I kinda gave up.
Re: BASH completion (written but not reviewed)
i don't have a prob including it with the project if you want to send it as a proper patch to the list -mike
This means that they will review if you submit it in a proper form.
@akinomyoga and I don't know what that proper form is, because I don't know where they would want that file in the tree, how it should be included/referenced, whether it needs a make action, etc. I don't write low-level C programs, so I'd probably just get it wrong.
It's not complicated to test; no compilation, no install, download and source a single script in bash. I took the response as ‘we'll look at this when you've done it the right way, but you haven't, and we won't tell you exactly what that is, so we won't look at it.’
The proper form is just the form of posting an email. There is a specific way of posting a patch in the mailing lists of traditional open-source projects, and there are reasons. However, you didn't follow it, which would cause problems. See other posts on the mailing list.
It's not related to how much the actual changes in the patch are correct or not. You should submit a patch with a temporary location of the file and wait for their comments. If they don't like the file location, they should tell you the preferred path.
whether it needs a
makeaction,
I'd say the make action should be included, or otherwise the file is likely to be used by no one. Anyway, you may ask it on the mailing list including the way how a make rule should be added.
@akinomyoga Exactly my point. I don't know what make action to include for installation across different distros, so any patch I put forth would likely be unacceptable. Last time, it took a year before I got any response. You're welcome to ask them if you like.
@akinomyoga Exactly my point. I don't know what
makeaction to include for installation across different distros, so any patch I put forth would likely be unacceptable.
That's not the problem. The first patch doesn't need to be at an acceptable level. It is normal to revise the patch multiple times after discussing each version of the submitted patch.
It just needs to be submitted in a proper form. I repeat that the proper form is not about the content of the patch. You provided the change with a link. This is one of the most problematic ways of posting anything on the mailing list. Links are in general considered to become unavailable in the future. On the other hand, we often need to look back on the mailing list log to investigate the background of the codebase, so all the discussions need to be trackable, i.e., all the necessary information should be included in the emails themselves. Otherwise, they can't even start a discussion. You are blocking the discussion there.
Last time, it took a year before I got any response. You're welcome to ask them if you like.
Honestly, this is the problem of the upstream acl project. It's not your fault. If you would like to communicate with them, you need to be patient. I'm not so enthusiastic to make it include the upstream.