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): gawk-3.1.4-5 How reproducible: Always Steps to Reproduce: 1. type: gawk 'BEGIN{"date " "+%Y" | getline year}' 2. 3. 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.
Please, see docs: http://www.gnu.org/software/gawk/manual/html_node/Getline_002fPipe.html#Getline_002fPipe 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.
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.
Patches have been created by gnu.org: http://lists.gnu.org/archive/html/bug-gnu-utils/2005-10/msg00078.html
Well, if the change will be accepted be upstream maintainer (Arnold) I will add the paths to FC5. Thanks.
sorry, s/paths/patches/ :-)
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.
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.