Re: awk doesn't build on armv7

[Jan Stary]

On Feb 02 11:49:50, stu.li...@spacehopper.org wrote:
> On 2022-02-02, Jan Stary  wrote:
> > #define noreturn __dead
> > #else
> > #include 
> > #endif
> >
> > and stdnoreturn.h indeed does not exist.
> 
> Where are you looking? It should be in 
> /usr/lib/clang/13.0.0/include/stdnoreturn.h.

I only looked in /usr/include, sorry.

After a sysupgrade, it compiles fine.

Jan

Re: awk doesn't build on armv7

[Stuart Henderson]

On 2022-02-02, Jan Stary  wrote:
>   #define noreturn __dead
>   #else
>   #include 
>   #endif
>
> and stdnoreturn.h indeed does not exist.

Where are you looking? It should be in 
/usr/lib/clang/13.0.0/include/stdnoreturn.h.

Re: awk doesn't build on armv7

[Theo de Raadt]

Builds fine for me.

Jan Stary  wrote:

> This is current/armv7 on a Beagle Bone  Black (dmesg below).
> make build just failed in usr.bin/awk with
> 
> ===> usr.bin/awk
> yacc -o awkgram.tab.c -d /usr/src/usr.bin/awk/awkgram.y
> /usr/src/usr.bin/awk/awkgram.y: yacc finds 62 shift/reduce conflicts
> /usr/src/usr.bin/awk/awkgram.y: yacc finds 87 reduce/reduce conflicts
> cc -O2 -pipe  -I. -I/usr/src/usr.bin/awk -DHAS_ISBLANK -DNDEBUG 
> -Werror-implicit-function-declaration -MD -MP  -c awkgram.tab.c
> In file included from /usr/src/usr.bin/awk/awkgram.y:29:
> /usr/src/usr.bin/awk/awk.h:32:10: fatal error: 'stdnoreturn.h' file not found
> #include 
>  ^~~
> 1 error generated.
> *** Error 1 in usr.bin/awk (:87 'awkgram.tab.o')
> 
> The include in awk.h happens like this:
> 
>   #if __STDC_VERSION__ <= 199901L
>   #define noreturn __dead
>   #else
>   #include 
>   #endif
> 
> and stdnoreturn.h indeed does not exist.
> 
> But the same compiles fine on amd64.
> 
>   Jan
> 
> 
> OpenBSD 7.0-current (GENERIC) #0: Mon Jan 31 17:41:46 CET 2022
> h...@bbb.stare.cz:/usr/src/sys/arch/armv7/compile/GENERIC
> real mem  = 484184064 (461MB)
> avail mem = 463847424 (442MB)
> random: good seed from bootblocks
> mainbus0 at root: TI AM335x BeagleBone Black
> cpu0 at mainbus0 mpidr 0: ARM Cortex-A8 r3p2
> cpu0: 32KB 64b/line 4-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
> cpu0: 256KB 64b/line 8-way L2 cache
> omap0 at mainbus0
> prcm0 at omap0 rev 0.2
> dmtimer0 at omap0 rev 3.1
> dmtimer1 at omap0 rev 3.1
> omsysc0 at mainbus0: "target-module"
> omsysc1 at omsysc0: "target-module"
> "pmu" at omsysc1 not configured
> simplebus0 at mainbus0: "ocp"
> intc0 at simplebus0 rev 5.0
> omsysc2 at simplebus0: "target-module"
> simplebus1 at simplebus0: "interconnect"
> simplebus2 at simplebus1: "segment"
> simplebus3 at simplebus1: "segment"
> omsysc3 at simplebus3: "target-module"
> "cpu" at omsysc3 not configured
> simplebus4 at simplebus1: "segment"
> omsysc4 at simplebus4: "target-module"
> simplebus5 at omsysc4: "prcm"
> omcm0 at simplebus5: "per-cm"
> omclock0 at omcm0: "l4ls-clkctrl"
> omclock1 at omcm0: "l3s-clkctrl"
> omclock2 at omcm0: "l3-clkctrl"
> omclock3 at omcm0: "l4hs-clkctrl"
> omclock4 at omcm0: "pruss-ocp-clkctrl"
> omclock5 at omcm0: "cpsw-125mhz-clkctrl"
> omclock6 at omcm0: "lcdc-clkctrl"
> omclock7 at omcm0: "clk-24mhz-clkctrl"
> omcm1 at simplebus5: "wkup-cm"
> omclock8 at omcm1: "l4-wkup-clkctrl"
> omclock9 at omcm1: "l3-aon-clkctrl"
> omclock10 at omcm1: "l4-wkup-aon-clkctrl"
> omcm2 at simplebus5: "mpu-cm"
> omclock11 at omcm2: "mpu-clkctrl"
> omcm3 at simplebus5: "l4-rtc-cm"
> omclock12 at omcm3: "l4-rtc-clkctrl"
> omcm4 at simplebus5: "gfx-l3-cm"
> omclock13 at omcm4: "gfx-l3-clkctrl"
> omcm5 at simplebus5: "l4-cefuse-cm"
> omclock14 at omcm5: "l4-cefuse-clkctrl"
> "prm" at simplebus5 not configured
> "prm" at simplebus5 not configured
> "prm" at simplebus5 not configured
> "prm" at simplebus5 not configured
> "prm" at simplebus5 not configured
> "prm" at simplebus5 not configured
> "prm" at simplebus5 not configured
> omsysc5 at simplebus4: "target-module"
> simplebus6 at omsysc5: "scm"
> syscon0 at simplebus6: "scm_conf"
> pinctrl0 at simplebus6
> "control" at simplebus6 not configured
> "wkup_m3_ipc" at simplebus6 not configured
> "dma-router" at simplebus6 not configured
> omsysc6 at simplebus4: "target-module"
> omgpio0 at omsysc6: rev 0.1
> gpio0 at omgpio0: 32 pins
> omsysc7 at simplebus4: "target-module"
> com0 at omsysc7: ti16750, 64 byte fifo
> com0: console
> omsysc8 at simplebus4: "target-module"
> tiiic0 at omsysc8 rev 0.11
> iic0 at tiiic0
> "ti,tps65217" at iic0 addr 0x24 not configured
> "atmel,24c256" at iic0 addr 0x50 not configured
> nxphdmi0 at iic0 addr 0x70: rev 0x0301
> nxphdmi0: no display detected
> omsysc9 at simplebus4: "target-module"
> omsysc10 at simplebus4: "target-module"
> "timer" at omsysc10 not configured
> omsysc11 at simplebus4: "target-module"
> omdog0 at omsysc11 rev 0.1
> omsysc12 at simplebus4: "target-module"
> "rtc" at omsysc12 not configured
> simplebus7 at simplebus0: "interconnect"
> simplebus8 at simplebus7: "segment"
> omsysc13 at simplebus8: "target-module"
> omsysc14 at simplebus8: "target-module"
> omsysc15 at simplebus8: "target-module"
> omsysc16 at simplebus8: "target-module"
> omsysc17 at simplebus8: "target-module"
> "mcasp" at omsysc17 not configured
> omsysc18 at simplebus8: "target-module"
> omsysc19 at simplebus8: "target-module"
> "timer" at omsysc19 not configured
> omsysc20 at simplebus8: "target-module"
> "timer" at omsysc20 not configured
> omsysc21 at simplebus8: "target-module"
> "timer" at omsysc21 not configured
> omsysc22 at simplebus8: "target-module"
> "timer" at omsysc22 not configured
> omsysc23 at simplebus8: "target-module"
> "timer" at omsysc23 not configured
> omsysc24 at simplebus8: "target-module"
> "timer" at omsysc24 not configured
> omsysc25 at simplebus8: 

Re: awk segfaults on RS regexp

[Todd C . Miller]

On Mon, 13 Jul 2020 13:02:44 +0200, Jan Stary wrote:

> This is current/amd64.
>
> On UTF input, awk segfaults when using a multi-character RS:
>
> $ cat /tmp/in
> č
>
> $ hexdump -C /tmp/in
>   c4 8d 0a|...|
> 0003
>
> $ cat /tmp/in | awk '{print$1}'
> č
>
> $ cat /tmp/in | awk -v RS=x '{print$1}'
> č
>
> $ cat /tmp/in | awk -v RS=xy '{print$1}'
> Segmentation fault (core dumped)

Nice catch.  The actual bug is caused by using a signed char as an
index into an array, resulting in a negative index.  Once debugged,
the fix is simple.

 - todd

diff --git a/b.c b/b.c
index c167b50..f7fbc0e 100644
--- a/b.c
+++ b/b.c
@@ -684,7 +684,7 @@ bool fnematch(fa *pfa, FILE *f, char **pbuf, int *pbufsize, 
int quantum)
FATAL("stream '%.30s...' too 
long", buf);
buf[k++] = (c = getc(f)) != EOF ? c : 0;
}
-   c = buf[j];
+   c = (unsigned char)buf[j];
/* assert(c < NCHARS); */
 
if ((ns = pfa->gototab[s][c]) != 0)

Re: awk in OpenBSD

[Adam Steen]

I would guess the latest update Dec, 2012, doesn't off any worth upgrading for,

[1]
Dec 20, 2012:
fiddled makefile to get correct yacc and bison flags. pick yacc
(linux) or bison (mac) as necessary.
added __attribute__((__noreturn__)) to a couple of lines in
proto.h, to silence someone's enthusiastic checker.
fixed obscure call by value bug in split(a[1],a) reported on
9fans. the management of temporary values is just a mess; i
took a shortcut by making an extra string copy. thanks
to paul patience and arnold robbins for passing it on and for
proposed patches.
tiny fiddle in setfval to eliminate -0 results in T.expr, which
has irritated me for 20+ years.

[1] 
https://github.com/danfuzz/one-true-awk/blob/master/versions/2012-12-20/FIXES

On Thu, Oct 19, 2017 at 1:14 PM, Niels Kobschaetzki
 wrote:
>
>> On 19. Oct 2017, at 06:23, flipchan  wrote:
>>
>> Yeah blindly follow the flow of the others , DONT THINK SO
>
> That doesn’t explain the reasoning WHY the newer awk is not used.
>
>>> On October 19, 2017 4:25:09 AM GMT+02:00, Andras Farkas 
>>>  wrote:
>>> On the 6.2 release page, and confirmed in the source code, one can see
>>> The system includes the following major components from outside
>>> suppliers:
>>> Awk Aug 10, 2011 version
>>> This turns out to be one release behind upstream, where the latest
>>> release is from December 20 2012: a quick check shows that
>>> DragonFlyBSD, FreeBSD, and NetBSD all use this version.
>>>
>>> Just out of curiosity, is there a reason why OpenBSD uses the 2011
>>> release?
>
> Niels

Re: awk in OpenBSD

[Theo de Raadt]

i'm watching a bunch of losers who argue before running diff


> You didn't really make a great case for the newer awk, either. Is there a
> good reason to use the 2012 release from upstream? If so, you could submit
> a diff and explain the benefits.
> 
> On Oct 19, 2017 12:15 AM, "Niels Kobschaetzki" 
> wrote:
> 
> 
> > On 19. Oct 2017, at 06:23, flipchan  wrote:
> >
> > Yeah blindly follow the flow of the others , DONT THINK SO
> 
> That doesn=E2=80=99t explain the reasoning WHY the newer awk is not used.
> 
> >> On October 19, 2017 4:25:09 AM GMT+02:00, Andras Farkas <
> deepbluemist...@gmail.com> wrote:
> >> On the 6.2 release page, and confirmed in the source code, one can see
> >> The system includes the following major components from outside
> >> suppliers:
> >> Awk Aug 10, 2011 version
> >> This turns out to be one release behind upstream, where the latest
> >> release is from December 20 2012: a quick check shows that
> >> DragonFlyBSD, FreeBSD, and NetBSD all use this version.
> >>
> >> Just out of curiosity, is there a reason why OpenBSD uses the 2011
> >> release?
> 
> Niels

Re: awk in OpenBSD

[Ax0n]

You didn't really make a great case for the newer awk, either. Is there a
good reason to use the 2012 release from upstream? If so, you could submit
a diff and explain the benefits.

On Oct 19, 2017 12:15 AM, "Niels Kobschaetzki" 
wrote:


> On 19. Oct 2017, at 06:23, flipchan  wrote:
>
> Yeah blindly follow the flow of the others , DONT THINK SO

That doesn’t explain the reasoning WHY the newer awk is not used.

>> On October 19, 2017 4:25:09 AM GMT+02:00, Andras Farkas <
deepbluemist...@gmail.com> wrote:
>> On the 6.2 release page, and confirmed in the source code, one can see
>> The system includes the following major components from outside
>> suppliers:
>> Awk Aug 10, 2011 version
>> This turns out to be one release behind upstream, where the latest
>> release is from December 20 2012: a quick check shows that
>> DragonFlyBSD, FreeBSD, and NetBSD all use this version.
>>
>> Just out of curiosity, is there a reason why OpenBSD uses the 2011
>> release?

Niels

Re: awk in OpenBSD

[Niels Kobschaetzki]

> On 19. Oct 2017, at 06:23, flipchan  wrote:
> 
> Yeah blindly follow the flow of the others , DONT THINK SO

That doesn’t explain the reasoning WHY the newer awk is not used. 

>> On October 19, 2017 4:25:09 AM GMT+02:00, Andras Farkas 
>>  wrote:
>> On the 6.2 release page, and confirmed in the source code, one can see
>> The system includes the following major components from outside
>> suppliers:
>> Awk Aug 10, 2011 version
>> This turns out to be one release behind upstream, where the latest
>> release is from December 20 2012: a quick check shows that
>> DragonFlyBSD, FreeBSD, and NetBSD all use this version.
>> 
>> Just out of curiosity, is there a reason why OpenBSD uses the 2011
>> release?

Niels

Re: awk in OpenBSD

[flipchan]

Yeah blindly follow the flow of the others , DONT THINK SO

On October 19, 2017 4:25:09 AM GMT+02:00, Andras Farkas 
 wrote:
>On the 6.2 release page, and confirmed in the source code, one can see
>The system includes the following major components from outside
>suppliers:
>Awk Aug 10, 2011 version
>This turns out to be one release behind upstream, where the latest
>release is from December 20 2012: a quick check shows that
>DragonFlyBSD, FreeBSD, and NetBSD all use this version.
>
>Just out of curiosity, is there a reason why OpenBSD uses the 2011
>release?

-- 
Take Care Sincerely flipchan layerprox dev

Re: Flex / Regexps (Re: awk regex bug)

[hruodr]

I wrote:

 [...] Why should
 be difficult to track the indices in yytext of the beginning and the end 
 of each matching subexpression, in two arrays of integers (one for
 the beginning and one for the end)? [...] 

More exactly: in the first array the index of the first element of
the matching subexpression, in the second the index of the last
element plus one. When both indices are equal, then the subexpression
is void. 

If the second index correspond to something irrelevant in yytext, then 
one can set yytext there to 0 for easily obtaining a pointer to a null 
terminating string equal to the subexpression.

Just dreaming.

Rodrigo.

Flex / Regexps (Re: awk regex bug)

[hruodr]

Otto Moerbeek o...@drijf.net wrote:

 Refering to subpatterns is not available in flex.  I suppose it is not
 available since it would require a more complex re engine.
 Interpretation of the lexical value should be hand-crafted. 

I also though caomplexity can be the reason, but I have doubts. Why should
be difficult to track the indices in yytext of the beginning and the end 
of each matching subexpression, in two arrays of integers (one for
the beginning and one for the end)? Neither memory nor time seems to
be a problem. And hand crafting means not only avoidable programming
work and unreadability, but a second pass that adds complexity.

A nice source on regexps is here:  https://swtch.com/~rsc/regexp/

In the first article listed there you read:


While writing the text editor sam [6] in the early 1980s, Rob Pike wrote a 
new regular expression implementation, which Dave Presotto extracted into 
a library that appeared in the Eighth Edition. Pike's implementation 
incorporated submatch tracking [sic!] into an efficient NFA simulation but, 
like the rest of the Eighth Edition source, was not widely distributed. 
Pike himself did not realize that his technique was anything new. Henry 
Spencer reimplemented the Eighth Edition library interface from scratch, 
but using backtracking, and released his implementation into the public 
domain. It became very widely used, eventually serving as the basis for 
the slow regular expression implementations mentioned earlier: Perl, PCRE, 
Python, and so on. (In his defense, Spencer knew the routines could be 
slow, and he didn't know that a more efficient algorithm existed. He 
even warned in the documentation, Many users have found the speed 
perfectly adequate, although replacing the insides of egrep with this 
code would be a mistake.) Pike's regular expression implementation, 
extended to support Unicode, was made freely available with sam in late 
1992, but the particularly efficient regular expression search algorithm 
went unnoticed. The code is now available in many forms: as part of sam, 
as Plan 9's regular expression library, or packaged separately for Unix. 
Ville Laurikari independently discovered Pike's algorithm in 1999, 
developing a theoretical foundation as well [2]. 


Note that OpenBSD's regex library seems to use the slow Spencer 
implementation.

Rodrigo.

Re: awk regex bug

[Otto Moerbeek]

On Mon, Jun 08, 2015 at 02:49:44PM +, hru...@gmail.com wrote:

 Otto Moerbeek o...@drijf.net wrote:
 
  Tradiotionally, { } pattersn are not part of awk re's.
 
  Posix added them, but we do not include them afaik. Gnu awk only accepts
  them if given an extra arg (--posix or --re-interval).
 
  I think this should be documented.
 
 Although there is a clear theory about regular expressions, I have the
 impression that there is no standard syntax. One needs to read again and
 again the documentation of programs that use them.
 
 I am just missing a way to reference in a (f)lex action a previously
 matched subexpression (like with \m in a substitution with ed).
 
 Why is this? Because lex is so old? And what does people do in these
 cases?
 
 Rodrigo

Refering to subpatterns is not available in flex.  I suppose it is not
available since it would require a more complex re engine.
Interpretation of the lexical value should be hand-crafted. 

-Otto

Re: awk regex bug

[hruodr]

Otto Moerbeek o...@drijf.net wrote:

 Tradiotionally, { } pattersn are not part of awk re's.

 Posix added them, but we do not include them afaik. Gnu awk only accepts
 them if given an extra arg (--posix or --re-interval).

 I think this should be documented.

Although there is a clear theory about regular expressions, I have the
impression that there is no standard syntax. One needs to read again and
again the documentation of programs that use them.

I am just missing a way to reference in a (f)lex action a previously
matched subexpression (like with \m in a substitution with ed).

Why is this? Because lex is so old? And what does people do in these
cases?

Rodrigo

Re: awk regex bug

[Otto Moerbeek]

On Thu, May 28, 2015 at 02:08:47AM -0500, cwl...@mst.edu wrote:

 Hi misc,
 
 I'm running a 5.7 release, and I'm wondering if anyone can confirm
 an awk bug I found.
 
 Curly brackets are treated as literal characters instead of bounds
 as specified by re_format(7).
 
 Reproduction:
 
 echo aa | awk '/a{2}/'
 
 produces no output instead of printing aa as expected.
 
 echo 'a{2}' | awk '/a{2}/'
 
 produces output when none is expected.
 
 This bug seems awk specific since the equivalents using grep
 
 echo aa | grep -E 'a{2}'
 
 echo 'a{2}' | grep -E 'a{2}'
 
 work as expected.

Tradiotionally, { } pattersn are not part of awk re's.

Posix added them, but we do not include them afaik. Gnu awk only accepts
them if given an extra arg (--posix or --re-interval).

I think this should be documented.

-Otto

Re: awk

[Denny White]

 On Thu, Jan 15, 2009 at 02:41:24PM +, Andreas Kahari spoke thusly:
 2009/1/15 igor denisov denisovigor1...@rambler.ru:
  Hi there
  Can not understand.
 
  input:
  34523 9348 98493 82983
  9485 83928 9283 9283
  394 39934 293 8347
  3456 9238 9283 9283
 
  awk 'NR==1 { for (i = 1; i = NF; i++) {n=$i; next}}; {n-=$i} END {print n}'
  input
 
  output:
  21188 it is first column, why?
 
 You should really take these questions to an awk forum, not to this
 mailing list.
 
 Your program reads the first record, and assigns its first column to
 'n' in a loop that is immediately exited (with 'next') and goes on to
 read the remaining records.
 
 For the remaining records, 'i' being still 1 from the prematurely
 exited loop, the first column is subtracted from 'n'.
 
 Regards,
 Andreas
 
 
 -- 
 Andreas Kahari
 Somewhere in the general Cambridge area, UK
 

Deleted original message, so replying to Andreas' message.

To sum by columns, do:
awk '{for(i=1;i=NF;i++)t[i]+=$i}END{for(i=1;i in t;i++)print t[i]}' \
input

If you want to sum by lines, do:
awk '{for(i=1;i=NF;i++)t[i]+=$i}END{for(i=1;i in t;i++)print t[i]}' \
input

If you want to total all the numbers at once you can do:
awk '{for(i=1;i=NF;i++)t[i]+=$i}END{for(i=1;i in t;i++)print t[i]}' \
input

If I misunderstood what you want, like do you just want to total
the first column, then:

awk '{print $1}' input | \
awk '{for(i=1;i=NF;i++)t[i]+=$i}END{for(i=1;i in t;i++)print t[i]}'

For another column, just change the '{print $1}' to whatever column
you need. The gurus might and probably do know a better way, but
that works. Hope this helps.


Denny White

-- 

 /\ASCII Ribbon Campaign
 \ /Respect for low technology.
  X Keep e-mail messages readable by any computer system.
 / \Keep it ASCII.
===
GnuPG key  : 0x1644E79A  |  http://wwwkeys.nl.pgp.net
Fingerprint: D0A9 AD44 1F10 E09E 0E67  EC25 CB44 F2E5 1644 E79A
===

Re: awk

[Denny White]

 On Sat, Jan 17, 2009 at 03:13:27AM -0600, Denny White spoke thusly:
  On Thu, Jan 15, 2009 at 02:41:24PM +, Andreas Kahari spoke thusly:
  2009/1/15 igor denisov denisovigor1...@rambler.ru:
   Hi there
   Can not understand.
  
   input:
   34523 9348 98493 82983
   9485 83928 9283 9283
   394 39934 293 8347
   3456 9238 9283 9283
  
   awk 'NR==1 { for (i = 1; i = NF; i++) {n=$i; next}}; {n-=$i} END {print 
   n}'
   input
  
   output:
   21188 it is first column, why?
  
  You should really take these questions to an awk forum, not to this
  mailing list.
  
  Your program reads the first record, and assigns its first column to
  'n' in a loop that is immediately exited (with 'next') and goes on to
  read the remaining records.
  
  For the remaining records, 'i' being still 1 from the prematurely
  exited loop, the first column is subtracted from 'n'.
  
  Regards,
  Andreas
  
  
  -- 
  Andreas Kahari
  Somewhere in the general Cambridge area, UK
  
 
 Deleted original message, so replying to Andreas' message.
 
 To sum by columns, do:
 awk '{for(i=1;i=NF;i++)t[i]+=$i}END{for(i=1;i in t;i++)print t[i]}' \
 input
 
 If you want to sum by lines, do:
 awk '{for(i=1;i=NF;i++)t[i]+=$i}END{for(i=1;i in t;i++)print t[i]}' \
 input
 
 If you want to total all the numbers at once you can do:
 awk '{for(i=1;i=NF;i++)t[i]+=$i}END{for(i=1;i in t;i++)print t[i]}' \
 input
 
 If I misunderstood what you want, like do you just want to total
 the first column, then:
 
 awk '{print $1}' input | \
 awk '{for(i=1;i=NF;i++)t[i]+=$i}END{for(i=1;i in t;i++)print t[i]}'
 
 For another column, just change the '{print $1}' to whatever column
 you need. The gurus might and probably do know a better way, but
 that works. Hope this helps.
 
 
 Denny White
 

Now I know I'm tired. I overlooked the subtraction part.

To subtract down through just the first column, do:

awk '{print $1}' input | \
awk 'NR==1 {n=$1; next}; {n-=$1} END {print n}'


For a 4 column file, to subtract through all 4 columns, do:

awk 'NR == 1 { d1 = $1; d2 = $2; d3 = $3; d4 = $4; next }{ d1 -= $1; \
d2 -= $2; d3 -= $3; d4 -= $4 } END { print d1, d2, d3, d4 }' input

And again, hope this helps.


Denny White 

-- 

() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
===
GnuPG key  : 0x1644E79A  |  http://wwwkeys.nl.pgp.net
Fingerprint: D0A9 AD44 1F10 E09E 0E67  EC25 CB44 F2E5 1644 E79A
===

Re: awk

[Andreas Kahari]

2009/1/15 igor denisov denisovigor1...@rambler.ru:
 Hi there
 Can not understand.

 input:
 34523 9348 98493 82983
 9485 83928 9283 9283
 394 39934 293 8347
 3456 9238 9283 9283

 awk 'NR==1 { for (i = 1; i = NF; i++) {n=$i; next}}; {n-=$i} END {print n}'
 input

 output:
 21188 it is first column, why?

You should really take these questions to an awk forum, not to this
mailing list.

Your program reads the first record, and assigns its first column to
'n' in a loop that is immediately exited (with 'next') and goes on to
read the remaining records.

For the remaining records, 'i' being still 1 from the prematurely
exited loop, the first column is subtracted from 'n'.

Regards,
Andreas


-- 
Andreas Kahari
Somewhere in the general Cambridge area, UK

Re: awk doesn't recognize all of EREs

[Jason McIntyre]

On Thu, Sep 04, 2008 at 12:35:20PM +0400, Vadim Zhukov wrote:
 Our awk do not recognize range regex operator ({n,m} syntax). But man 
 page says:
 
 awk supports extended regular expressions (EREs). See re_format(7) for 
 more information on regular expressions.
 
 This behavior is same as in FreeBSD. gawk recognize range operator in 
 POSIX mode (--posix).
 
 As far as I understand, either our awk should recognize range operator 
 (better) or this non-POSIX behavior should be mentioned in awk(1). 
 Sample diff for man page provided; I didn't dig deeply in code to fix it 
 enough yet.
 

slightly different diff to yours committed. thanks for the mail,
jmc