Disclaimer The following, first solution is outdated due to a misinterperation of the original question. Please refer to edits 1 & 2 for matching solutions.
awk
does not recognise commas as separators by default. It does so for tabs and spaces only. You will thus need to define the separator explicitly, otherwise awk
compares a string value.
BEGIN {FS=","}
$1 > 1000
Note that I also used the simplified notation where a line is printed when a condition is met. This just as a hint for simpler code.
Or specify the separator on the command line:
awk -F, -f script.awk infile
Edit 1 following specification that ,
is to be used as decimal separator.
Please be aware that awk
will consider .
as decimal separator and using the locale settings for decimal separators is usually troublesome.
For Option 1, I'd suggest using a little trick: Still take integer and fraction as separate, comma-delimited fields and evaluate them individually:
BEGIN {FS=","}
$1==1000 && $2>0 || $1 > 1000
This will a) skip trying to use locale in awk
and b) skip trying to translate back and forth between ,
- and .
-separation.
The disadvantage being that in case there is more floating point data, the field numbers might not match column headers. However if it really is just about printing matching lines, this does not play a role.
An infile like
1,151
1001,055
756,75788
1000
1000,00
1000,000001
would return
1001,055
1000,000001
Edit 2 Another, probably more elegant, option is translating the first field into a dot-separated floating for the comparison:
gensub(/,/,".","g",$1)+0 > 1000
This works as follows: Interpret field 1 as string, replace ,
by .
, add 0
to make it into a number in awk
-logic, do the comparison and print if condition is true. The advantage is that with the specification of ;
as field separator, this solution does not introduce problems with field numbers.
In general, I'd suggest trying to avoid ,
as decimal separator as far as possible. Of course this depends on who provides the data.
C
(akaPOSIX
) locale which many tools use for portability and efficiency, see unix.stackexchange.com/a/87763/133219 for more info on that locale.,
as the decimal point, you should be able to get the desired result by invoking it with--use-lc-numeric
. See for example 6.1.4.2 Locales Can Influence Conversion