[arch-projects] rc.d bash_completion

[Seblu]

On Thu, Jun 9, 2011 at 2:43 PM, Dave Reisner <d at falconindy.com> wrote:
>>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.

Functionnality is useful, but i agree on two points.


-- 
Sébastien Luttringer
www.seblu.net