Hermann Peifer | 30 Oct 14:55 2010
Picon

Re: Unexpected result while constructing strings

On 30/10/2010 13:13, Davide Brini wrote:
>
> Back to the example, I may be wrong but the only way I see for FS ++c to
> evaluate to plain 0 is that for some reason they are grouped as
>
> FS + +c
>
> since c is 0, "+c" is also 0, and the result of the "addition" between FS
> and "+c" is 0.
>
> FWIW, mawk shows the same behavior.
>

Thanks for the pointer to the FAQ. Any idea about this one:

$ gawk-stable/gawk 'BEGIN{ c++ ; print FS ++c }'
01

$ gawk-stable/gawk 'BEGIN{ c++ ; print (FS) ++c }'
  2

Davide Brini | 30 Oct 15:18 2010
Picon

Re: Unexpected result while constructing strings

On Sat, 30 Oct 2010 14:55:43 +0200 Hermann Peifer <peifer <at> gmx.eu> wrote:

> On 30/10/2010 13:13, Davide Brini wrote:
> >
> > Back to the example, I may be wrong but the only way I see for FS ++c to
> > evaluate to plain 0 is that for some reason they are grouped as
> >
> > FS + +c
> >
> > since c is 0, "+c" is also 0, and the result of the "addition" between
> > FS and "+c" is 0.
> >
> > FWIW, mawk shows the same behavior.
> >
> 
> Thanks for the pointer to the FAQ. Any idea about this one:
> 
> $ gawk-stable/gawk 'BEGIN{ c++ ; print FS ++c }'
> 01
> 
> $ gawk-stable/gawk 'BEGIN{ c++ ; print (FS) ++c }'
>   2

To be honest, no. That leading 0 is puzzling, although it's clearly due to
FS being converted to numeric (using another variable does the same). 
It seems the issue is definitely related to the order of evaluation in
string concatenation.

In the sceond case, mawk and gawk behave differently:

(Continue reading)

Hermann Peifer | 30 Oct 16:00 2010
Picon

Re: Unexpected result while constructing strings

On 30/10/2010 15:18, Davide Brini wrote:
> On Sat, 30 Oct 2010 14:55:43 +0200 Hermann Peifer<peifer <at> gmx.eu>  wrote:
>
>> On 30/10/2010 13:13, Davide Brini wrote:
>>> Back to the example, I may be wrong but the only way I see for FS ++c to
>>> evaluate to plain 0 is that for some reason they are grouped as
>>>
>>> FS + +c
>>>
>>> since c is 0, "+c" is also 0, and the result of the "addition" between
>>> FS and "+c" is 0.
>>>
>>> FWIW, mawk shows the same behavior.
>>>
>> Thanks for the pointer to the FAQ. Any idea about this one:
>>
>> $ gawk-stable/gawk 'BEGIN{ c++ ; print FS ++c }'
>> 01
>>
>> $ gawk-stable/gawk 'BEGIN{ c++ ; print (FS) ++c }'
>>    2
> To be honest, no. That leading 0 is puzzling, although it's clearly due to
> FS being converted to numeric (using another variable does the same).
> It seems the issue is definitely related to the order of evaluation in
> string concatenation.
>
> In the sceond case, mawk and gawk behave differently:
>
> $ gawk 'BEGIN{ c++ ; print (FS) ++c }'
>   2
(Continue reading)

Davide Brini | 30 Oct 16:05 2010
Picon

Re: Unexpected result while constructing strings

On Sat, 30 Oct 2010 16:00:20 +0200 Hermann Peifer <peifer <at> gmx.eu> wrote:

> I think I got it now: `FS ++c' is not (mis)interpreted as `FS + +c', but 
> rather as `FS++ c'. See below. Let's see if Arnold agrees.
> 
> Hermann
> 
> $ cat data
> A
> B
> C
> $ gawk-stable/gawk --dump-variables '{ print FS ++c }' data ; tail -n1 
> awkvars.out
> 0
> 1
> 2
> c: string ("")
> $ gawk-stable/gawk --dump-variables '{ print FS++ c }' data ; tail -n1 
> awkvars.out
> 0
> 1
> 2
> c: string ("")

Thanks. It seems you're right indeed:

$ gawk 'BEGIN{ c++; print FS ++c ; print FS}'
01
1
$ gawk --dump-variables 'BEGIN{ c++; print FS++ c ; print FS}'
(Continue reading)

Hermann Peifer | 30 Oct 16:38 2010
Picon

Re: Unexpected result while constructing strings

On 30/10/2010 16:05, Davide Brini wrote:
> On Sat, 30 Oct 2010 16:00:20 +0200 Hermann Peifer<peifer <at> gmx.eu>  wrote:
>
>> I think I got it now: `FS ++c' is not (mis)interpreted as `FS + +c', but
>> rather as `FS++ c'. See below. Let's see if Arnold agrees.
>>
>> Hermann
>>
>> $ cat data
>> A
>> B
>> C
>> $ gawk-stable/gawk --dump-variables '{ print FS ++c }' data ; tail -n1
>> awkvars.out
>> 0
>> 1
>> 2
>> c: string ("")
>> $ gawk-stable/gawk --dump-variables '{ print FS++ c }' data ; tail -n1
>> awkvars.out
>> 0
>> 1
>> 2
>> c: string ("")
> Thanks. It seems you're right indeed:
>
> $ gawk 'BEGIN{ c++; print FS ++c ; print FS}'
> 01
> 1
> $ gawk --dump-variables 'BEGIN{ c++; print FS++ c ; print FS}'
(Continue reading)

Andreas Schwab | 30 Oct 17:27 2010

Re: Unexpected result while constructing strings

Hermann Peifer <peifer <at> gmx.eu> writes:

> Just to add another (somewhat surprising) result:
>
> $ gawk-stable/gawk --dump-variables '{ print -- FS++ c }' data ; egrep

This is parsed as `(--FS) (++c)', so nothing surprising.

Andreas.

--

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Andreas Schwab | 30 Oct 16:43 2010

Re: Unexpected result while constructing strings

Davide Brini <dave_br <at> gmx.com> writes:

> That would explain the leading 0 (FS converted to number before the
> postincrement). Still, it seems weird to me that "FS ++c" is parsed
> as being a postincrement for FS, despite the intervening space.

Spaces are only significant as being token separators, but otherwise
ignored.

Andreas.

--

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Davide Brini | 30 Oct 16:39 2010
Picon

Re: Unexpected result while constructing strings

On Sat, 30 Oct 2010 16:43:28 +0200 Andreas Schwab <schwab <at> linux-m68k.org>
wrote:

> Davide Brini <dave_br <at> gmx.com> writes:
> 
> > That would explain the leading 0 (FS converted to number before the
> > postincrement). Still, it seems weird to me that "FS ++c" is parsed
> > as being a postincrement for FS, despite the intervening space.
> 
> Spaces are only significant as being token separators, but otherwise
> ignored.

I was just rereading the grammar more accurately now, and I found that in
the "lexical conventions" listed after the grammar. Thanks.

--

-- 
D.

Aharon Robbins | 30 Oct 20:09 2010

Re: Unexpected result while constructing strings

The notes so far have pretty much got it.  Concatenation in awk isn't
based on an explicit space character, but on juxtaposition.  In short,
it's a PITA and tends to make my head hurt sometimes; an explicit operator
would have been better. (Brian Kernighan once told me, about this, "it
seemed like a good idea at the time". :-)

One of my favorites was trying, many years ago now, to figure out why

	print("some diagnostic of interest") > /dev/stderr

wasn't working like I expected.  :-) :-)

Thanks to everyone for the explanations.

Arnold
--

-- 
Aharon (Arnold) Robbins 			arnold AT skeeve DOT com
P.O. Box 354		Home Phone: +972  8 979-0381
Nof Ayalon		Cell Phone: +972 50  729-7545
D.N. Shimshon 99785	ISRAEL

Andreas Schwab | 30 Oct 17:04 2010

Re: Unexpected result while constructing strings

Hermann Peifer <peifer <at> gmx.eu> writes:

> Thanks for the pointer to the FAQ. Any idea about this one:
>
> $ gawk-stable/gawk 'BEGIN{ c++ ; print FS ++c }'
> 01

This is parsed as `(FS++) c', where (FS++) is 0 and c is 1.

> $ gawk-stable/gawk 'BEGIN{ c++ ; print (FS) ++c }'
>  2

Here " " (FS) is concatented with 2 (++c).

Andreas.

--

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


Gmane