[Bug 12981] awk: seems to try to falsely expand strings

Sat Jun 6 21:12:11 UTC 2020

https://bugs.busybox.net/show_bug.cgi?id=12981

--- Comment #4 from Steffen Nurpmeso <steffen at sdaoden.eu> ---
Actually does not seem to work out.
I paste it here.
Thanks.

---

Oh hello i see and try replying!

Good evening.

Bernhard Reutner-Fischer wrote in
<20200606021709.4f5cd8bf at nbbrfq.cc.univie.ac.at>:
 |On Fri, 05 Jun 2020 19:50:07 +0000
 |bugzilla at busybox.net wrote:
 |> https://bugs.busybox.net/show_bug.cgi?id=12981
 ...
 |> But yes i indeed can.  Here mawk, mawk-debian, nawk, gawk:

And SunOS 5.9 /usr/bin/xpg4.

 |That's great, thanks alot for this simplification!

Hm.

 |>  #?0|kent:tmp$ </dev/null awk -v i=1 'BEGIN {print "hey fish " ++i "."}'
 |>  hey fish 2.
 ...
 |> Any why has it to be minimal, i never found a test series for busybox \
 |> (i looked
 |
 |I didn't say minimal. I said "small, self-contained".
 |
 |In your bug-report, you referenced a
 |IN="${SRCDIR}"su/gen-errors.h
 |which you did not attach. Although i could probably construct an input

It worked like shown.  I gave the necessary command line.  Sorry.
But please, at least i have stripped 251 lines of perl code before
attaching the file.  (vim fold.)

 |that exposes the alleged misbehaviour (or maybe i would not be able to
 |if it was another kind of bug as we're dealing with here) i would have
 |to guess. You did not provide a readily testable reproducer for us to
 |debug. We'd have to guess or suspect the problem to be obscured by an

That is not true really.

 |overly complex, incomplete testcase. This is very discouraging a
 |situation if you just have a couple of minute to read through a report
 |while, let's say, you are in the bus on your way home after eight or
 |thirteen hours of work.

Yes, it is good now.

I must have confused something.  Indeed testsuite came in Y2K1.

 |usually test some prominent cases with external testsuites. We used to
 |(and still some of us do) build our setups with busybox alone so the
 |most visible stuff supposedly works fine. In order not to regress we
 |strive to flesh out the internal testsuite. Except for network related
 |stuff which would usually be rather complicated to regtest in our
 |current testsuite due to it's simplicity.
 |
 |>
 |> I have asked Aharon Robbins for that "++i should be (++i)" of yours.
 |
 |Name dropping usually doesn't work for me for i know nothing, but sure,
 |if he knows awk land i'm all ears -- whoever that may be.. Please
 |excuse my ignorance.

You know i wondered whether i should response at all because of
that pissing stuff.  But i did.

 |> He kindly proved me wrong regarding my boolean use of getline() not \
 |> getline()>0
 |> already, i had to fix that in several places.  If he responds to \
 |> support my
 |> prefix/postfix in/decrement has highest priority .. i'll be back :-)
 |
 |looking forward to that.
 |>
 |> A nice weekend everybody i (who hates web interfaces like this, i \
 |> wished i
 |> could simply respond via email) wish from Germany,
 |
 |web interfaces are great to not forget stuff, but sure,
 |let's just take this to the list for a wider audience and easier
 |interaction for both of us.

These are in fact almost his words in our thread on the nawk bug,
because i do not have a github account and asked him whether
private mail would be ok.
Does not seem i get a response.
 |Folks, recap.
 |So, in this bug-reoprt what we have is:
 |- there is no awk standard (that i'm aware of at least; SuS is
 |  silent)
 |- awk has no (well) defined string-concatination precedence
 |- some (well) documented awk implementations explicitly warn
 |  script-authors to rely on precedence around string concatenation,
 |  like e.g.:
 |  https://www.gnu.org/software/gawk/manual/html_node/Concatenation.html

I have never read anything like that in any manual page of all the
awks i have or have seen.  (On CRUX-Linux there is no info system,
no info files.)  Many warn due to problematic number / string as in

 There  are  no  explicit  conversions  between  numbers  and
     strings.  To  force an expression to be treated as a number,
     add 0 to it. To force an  expression  to  be  treated  as  a
     string, concatenate the null string ("") to it.
  SunOS 5.9            Last change: 7 Jul 2000                    7

Over there there is /usr/bin/awk, which only works when passed
a script file via -f (where -f - works too), and this one really
behaves like the awk you are protecting from moving forward.

 |---8<---
 |Because string concatenation does not have an explicit operator, it \
 |is often necessary to ensure that it happens at the right time by using \
 |parentheses to enclose the items to concatenate.
 |---8<---
 |- new users of awk usually expect a well resp. clearly defined language
 |  but IMHO we do not face the luxory to deal with that in this context.
 |  Rule of least surprise for the user applies, as usual. Undefined
 |  corners of underspecified tools/behaviour is usually clarified
 |  centrally (by a standard of some sorts to back up claims or document
 |  consensus umong implementors). No such luxory here AFAIK.
 |- If you write your scripts defensively (i.e. know your stuff, to
 |  phrase it politely) all is well even with current busybox awk (see
 |  below)

I think i will in the future not respond to messages coming from
you, really.  Again, i have never ever read anything about that
behaviour in any of the awks i have seen.  mawk and debian-mawk
(manual date Dec 22 1994) both say

 Functions can be referenced before they are defined, but the
 function name and the '(' of the arguments must touch to avoid
 confusion with concatenation.

Hey.  I would suspect the rule of least surprise would in
a "modern" environment support moving busybox awk to where the
others are.

 |Bad:
 |$ ./busybox awk -v i=1 'BEGIN {print "fourty " ++i "."}'
 |01.
 |
 |Expected:
 |$ ./busybox awk -v i=1 'BEGIN {print "fourty " (++i) "."}'
 |fourty 2.
 |
 |Proposed fixes?
 |Follow up further improvements for awk? Equally robustness improvements \
 |to deal with possible similar cases you might make up while testing \
 |or debugging stuff? Or maybe you spot some areas that are written way \
 |too elaborate and you can save some bytes after having fixed this unspec\
 |ified but seemingly widely supported precedence convention?
 |
 |> Ciao,
 |
 |cheers and have phun,

That surely goes in the wrong direction man. :)

Ciao and a nice Sunday i wish.,

 --End of <20200606021709.4f5cd8bf at nbbrfq.cc.univie.ac.at>

-- 
You are receiving this mail because:
You are on the CC list for the bug.