14.5 Limitations

We hope you find the gawk debugger useful and enjoyable to work with, but as with any program, especially in its early releases, it still has some limitations. A few that it’s worth being aware of are:

• At this point, the debugger does not give a detailed explanation of what you did wrong when you type in something it doesn’t like. Rather, it just responds ‘syntax error’. When you do figure out what your mistake was, though, you’ll feel like a real guru.
• If you perused the dump of opcodes in Miscellaneous Debugger Commands (or if you are already familiar with gawk internals), you will realize that much of the internal manipulation of data in gawk, as in many interpreters, is done on a stack. Op_push, Op_pop, and the like are the “bread and butter” of most gawk code.

  Unfortunately, as of now, the gawk debugger does not allow you to examine the stack’s contents. That is, the intermediate results of expression evaluation are on the stack, but cannot be printed. Rather, only variables that are defined in the program can be printed. Of course, a workaround for this is to use more explicit variables at the debugging stage and then change back to obscure, perhaps more optimal code later.

• There is no way to look “inside” the process of compiling regular expressions to see if you got it right. As an awk programmer, you are expected to know the meaning of /[^[:alnum:][:blank:]]/.
• The gawk debugger is designed to be used by running a program (with all its parameters) on the command line, as described in Debugger Invocation. There is no way (as of now) to attach or “break into” a running program. This seems reasonable for a language that is used mainly for quickly executing, short programs.
• The gawk debugger only accepts source code supplied with the -f option.