Bug 173709 - Precedence changed without warning or documentation
Summary: Precedence changed without warning or documentation
Alias: None
Product: Fedora
Classification: Fedora
Component: gawk (Show other bugs)
(Show other bugs)
Version: 4
Hardware: i386 Linux
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2005-11-19 04:26 UTC by JW
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-12-03 21:12:12 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description JW 2005-11-19 04:26:59 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b) Gecko/20050217

Description of problem:
The precendence of gawk's pipeline operator (|) has changed without any warning.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. type: gawk 'BEGIN{"date " "+%Y" | getline year}'

Actual Results:  sh: +%: invalid option
(that is, sh is trying to execute "+%Y")

Expected Results:  no output

Additional info:

Previous versions of gawk would perform string concatenation with higher precedence than pipeline.
So the above example would be equivalent to "date +%Y" | getline.
This change breaks lots of existing awk scripts.

Comment 1 Karel Zak 2005-11-21 12:47:19 UTC
Please, see docs:

According to POSIX, `expression | getline' is ambiguous if expression contains
unparenthesized operators other than `$'âfor example, `"echo " "date" | getline'
is ambiguous because the concatenation operator is not parenthesized. You should
write it as `("echo " "date") | getline' if you want your program to be portable
to other awk implementations. 

gawk 'BEGIN{ ("date " "+%Y") | getline year}'

... works fine.

Sorry, closing as NOTABUG.

Comment 2 JW 2005-11-21 14:19:23 UTC
I disagree.
The new implementation is totally incompatible with all previous versions.
There was never any abiguity.

The alternative interpretation:

      "one" ("two" | getline)

can never have any sensible purpose because getline returns an integer result
but it wouldnt be clear exactly how that might be combined with the "two".
So what on earth is the value in the above parentheses?
I cannot understand why anyone would want to implement a precedence which always
leads to meaningless statements. 

Sorry, you and POSIX are quite wrong.  But that wouldn't be the first time.

Comment 3 JW 2005-12-01 09:28:05 UTC
Patches have been created by gnu.org:


Comment 4 Karel Zak 2005-12-01 10:14:12 UTC
Well, if the change will be accepted be upstream maintainer (Arnold) I will add
the paths to FC5. Thanks.

Comment 5 Karel Zak 2005-12-01 10:16:01 UTC
sorry, s/paths/patches/ :-)

Comment 6 Karel Zak 2005-12-03 21:12:12 UTC
From upstream mailing list:

  > Arnold, will you accept these patches?

  I am inclined at the moment not to accept the patches.  They add considerable
  complexity to the grammar to fix what is, in my opinion, a corner case, and 
  one that should be parenthesized anyways. This issue is also documented in
  the gawk manual.

Closing as NOTABUG.

Comment 7 JW 2005-12-03 23:40:37 UTC
But these patches are being added to the mainstream source. So does this mean
that Fedora/RedHat are now going to be creating their own branch of gawk?

Also, the patches were added by the same person whose patches created the
problem in the first place.  Shouldn't it therefore mean that Fedora/Redhat
should not have accepted the original faulty patches?

Also, the patches do not add considerable complexity to the grammar. Besides
most gawk users do not read the code so what on earth has complexity got to do
with it?  It is more important for things to work properly.

If life was about eliminating complexity then you wouldn't have a car.

Note You need to log in before you can comment on or make changes to this bug.