| 1 |
On 18/08/2014 15:18, Kerin Millar wrote: |
| 2 |
> On 18/08/2014 15:02, Stroller wrote: |
| 3 |
>> |
| 4 |
>> On Mon, 18 August 2014, at 1:16 pm, Kerin Millar |
| 5 |
>> <kerframil@×××××××××××.uk> wrote: |
| 6 |
>> ... |
| 7 |
>>> (( count += matches )) |
| 8 |
>>> done < <(grep -hcm1 -F "$string" ${files[*]}) |
| 9 |
>> |
| 10 |
>> Oh, this is lovely. |
| 11 |
>> |
| 12 |
>> I've learned some things today. |
| 13 |
>> |
| 14 |
>>> if (( count == ${#files[@]} )); then |
| 15 |
>> |
| 16 |
>> May I ask why you prefer these brackets for evaluation, please? |
| 17 |
> |
| 18 |
> There was no particular reason, other than to maintain consistency in |
| 19 |
> the example (both for evaluation and as an alternative to expansion). |
| 20 |
> Sometimes, I find double square brackets to be a bit of an eyesore, but |
| 21 |
> do tend to use them more often than not. |
| 22 |
> |
| 23 |
> I particularly like double parentheses for checking exit codes assigned |
| 24 |
> to variables. For example: |
| 25 |
> |
| 26 |
> (( $? )) && echo "something went wrong" |
| 27 |
> |
| 28 |
> As opposed to having to perform an explicit comparison: |
| 29 |
> |
| 30 |
> [[ $? != 0 ]] && echo "something went wrong" |
| 31 |
|
| 32 |
Oops, I meant to use the -ne operator there. Not that it actually makes |
| 33 |
a difference for this test. |
| 34 |
|
| 35 |
--Kerin |
Archives