[arch-projects] rc.d bash_completion

[Dave Reisner]

>On Wed, Jun 08, 2011 at 01:32:36PM +0200, Andrwe wrote:
> So here is a version which should satisfy your hints.
> Why should I always use an array?
> It's easier to manipulate a string using bash internals than
> manipulating an array.
> Because of that I had to remove a functionality of the script
> because I don't know how I can merge two arrays by removing all
> elemts which can be found in both arrays without using multiple
> for-loops.

Sorry, I fail to see how keeping things as strings makes things
_easier_. In my experiences, and as shown here, it leads to complex
solutions which are not easy to read. I've still yet to sit down and
really grok what the hell is going on in that regex.

Set subtraction and intersection can be done using grep or comm. I
prefer grep as it doesn't require the inputs to be sorted. For
example:

We can do intersection... elements from array1 are matched with elements
from array2.

  $ grep -xFf <(printf '%s\n' "${array1[@]}") <(print '%s\n' "${array2[@]}")

We can do subtraction... array1 is subtracted from array2.

  $ grep -vxFf <(printf '%s\n' "${array1[@]}") <(print '%s\n' "${array2[@]}")

And if all else fails, really, what's the problem with using nested
for loops? It's iteration of small datasets using bash builtins. That's
guaranteed to be fast enough for this.

I've still got 2 major concerns:

1) You're parsing Bash which you expect to have a specific form, when in
fact, there is no required format. Someone could easily come along and
create a script which your completion cannot handle. For all this added
complexity, you get functionality which is going to be rarely used. I,
of course, don't have the final say in this, but I really prefer the
simplicity of our current approach. That said, it does have some bugs. I
encourage you to fix them. Which brings me to point 2...

2) This is still a code dump, and as such, I don't think anyone will
accept this regardless of how good or bad it is. You've created a diff
of your script versus what we currently have in git (and not the
official git). We accept properly formed patches (that means commit
messages) sent with git-send-email. Alternatively, I know Tom is a fan
of pull requests from remote branches, such as my initscripts or
mkinitcpio repos on Github.

regards,
dave