Awk Technical Notes

Summary

AWK technical notes March 2023 In the previous article Fascination with AWK we discussed why AWK is great for prototyping and is often the best alternative to the shell and Python. In this article I want to show you some interesting technical facts I learned about AWK. Lack of GC AWK was designed to not require a GC (garbage collector) for its implementation. By the way, just like sh/bash. (I learned this remarkable fact from the oilshell blog – rather interesting technical blog, where author describes his progress in creating the “better bash”). The most substantial consequence is that it’s forbidden to return an array from a function, you can return only a scalar value. function f() { a[1] = 2 return a # error } However, you can pass an array to a function and fill it there BEGIN { fill(arr) print arr[0] " " arr[1] } function fill(arr, i) { arr[i++] = "hello"; arr[i++] = "world" } The thing is, in a lack of GC all heap allocations must be deterministic. That is, array, declared locally in a function must be destroyed at the moment when function returns. That’s why it’s disallowed to escape the declaration scope of a function (via return). The absense of GC allows to keep the language implementation very simple, thus fast and portable. Also, with predictable memory consumption. To me, this qualifies AWK as perfect embeddable language, although, for some reason this niche is firmly occupied by (GC-equipped) Lua. Local variables All variables are global by default. However, if you add a variable to the function parameters (like i above) it becomes local. JavaScript works in a similar way, although there are more suitable var/let/const keywords. In practice, it is customary to separate “real” function parameters from “local” parameters with additional spaces for clarity. Although Brian Kernighan (the K in AWK) regrets this design, in practice it works just fine. The notation for function locals is appalling (all my fault too, which makes it worse). So it appears, the ...