I have a large file called an.txt:
head -n 6 an.txt
Type Details Particulars Code Reference Amount Date ForeignCurrencyAmount ConversionCharge
Bank Fee Monthly A/C Fee -8.50 31/03/2021
Eft-Pos Rutherford & Bond 4835******** 8848 C 210331123119 -250.00 31/03/2021
Payment Avery Johnson Avery Johnso 592315 Labour -131.60 31/03/2021
Bill Payment Collins Tf 127 Driver Crescent I1600 50.00 31/03/2021
Bill Payment Becta Ltd Taylormallon Lawns Inv 1447 46.00 31/03/2021
.
.
.
I have written the following script called b1.awk:
#! /usr/bin/awk -f
BEGIN{
FS = "\t"
}
$2 ~ /Lance Te/ {
s+=$6
}
END{
print "Lance Te Patu: " s
}
BEGIN{
FS = "\t"
}
$2 ~ /Matti/ {
s+=$6
}
END{
print "Mattingly Court: " s
}
When called ./b1.awk an.txt I get:
Lance Te Patu: 3170.17
Mattingly Court: 3170.17
The first thing here is that the results are incorrect. The first one is correct but the second should be different. I am not sure why this does not work. The second question is whether /Lance Te/ and /Matti/ can be passed as variables rather than writing seperate awk statements which is what I ideally would like to achieve. I am sorry but I am trying to wrap my head around awk in case this seems a bit dumb to some of you.
>Solution :
You are requiring a fair bit of mind reading, but my crystal ball suggests you might be looking for something like
awk -F '\t' -v regex="Matti|Lance Te" '$2 ~ regex { sum[$2] += $6 }
END { for (rcpt in sum) print rcpt ": " sum[rcpt] }' an.txt
where I have assumed that you want to extract the full text from $2 as the actual recipient, although the regex looks for just a substring in each case.
In some more detail, we collect the interesting totals into an associative array sum where the key for each value is the string from $2 and the value is the accrued total of values for $6 from the rows where the key was found.
The immediate problem with your attempt was that you used the same variable s for each sum; you could trivially fix it by using t instead of s in the second set of statements. But repeating the code for each search string is obviously inelegant, cumbersome, and error-prone.