a2p - Awk-to-Perl translator


a2p [options] filename


The a2p(1) utility takes an awk(1) script specified on the command line (or from standard input) and produces a comparable perl(1) script on the standard output.


Set debugging flags.
Tell a2p(1) that this awk(1) script is always invoked with this -F switch.
Specify the names of the input fields if input does not have to be split into an array. For example, to translate an awk(1) script that processes the password file, you might use:
a2p -7 -nlogin.password.uid.gid.gcos.shell.home
You can use any delimiter to separate the field names.
Causes a2p(1) to assume that input will always have the number of fields indicated by -number.


Although a2p(1) translates fairly well, it is not completely reliable. In some cases, you might want to examine and adjust the Perl script it has produced. The examples provided below are such cases; they are given in no particular order.

There is an awk(1) idiom of putting int() around a string expression to force numeric interpretation even though the argument is always integer. This is usually unnecessary in perl(1). Because a2p(1) is unable to discern whether the argument is always going to be integer, however, it leaves it in. You might want to remove it.

Perl(1) differentiates numeric comparison from string comparison. Awk(1) has one operator for both that decides at run time which comparison to do. A2p(1) does not try to do a complete awk(1) emulation at this point. Instead, it guesses which one you want. It is usually right, but is not entirely reliable. All such guesses are marked with the comment ``#???''. It is recommended that you check them. You might also want to run at least once with the -w switch to perl(1), which warns you if you use == where you should have used eq.

Perl(1) does not attempt to emulate the behavior of awk(1) in which nonexistent array elements spring into existence simply by being referenced. If you are relying on this mechanism to create null entries for a subsequent for ... in, they will not be there in perl(1).

If a2p(1) makes a split line that assigns to a list of variables that looks like (Fld1, Fld2, Fld3...) you might want to rerun a2p(1) using the -n option mentioned above. You will then be able to name the fields throughout the script. If it splits to an array instead, the script is probably referring to the number of fields somewhere.

The exit statement in awk(1) does not necessarily exit; it goes to the END block if there is one. Awk(1) scripts that attempt within the END block to bypass the block under such circumstances can be simplified by removing the conditional statement in the END block and exiting directly from the perl(1) script.

Perl(1) has two kinds of array: numerically indexed and associative. Awk(1) arrays are usually translated to associative arrays, but if you know that the index is always going to be numeric you could change the {...} to [...]. Iteration over an associative array is done using the keys() function, but iteration over a numeric array is not. You might need to modify any loop that is iterating over a particular array.

Awk(1) starts by assuming OFMT has the value %.6g. Perl(1) starts by assuming its equivalent, $#, to have the value %.20g. Set $# explicitly if you use the default value of OFMT.

Near the top of the line loop will be the split operation that is implicit in the awk(1) script. There are times when you can move this down past some conditionals that test the entire record so that the split is not done as often.

For aesthetic reasons you may want to change the array base $[ from 1 back to the perl(1) default of 0, but you must also change all array subscripts and all substr() and index(3) operations to match.

Gratuitous comments that say "# Here is a workaround because awk is dumb" are passed through unmodified.

Awk(1) scripts are often embedded in a shell script that pipes data into and out of awk(1). Often the shell script wrapper can be incorporated into the perl(1) script, since perl(1) can start up pipes into and out of itself, and can do other things that awk(1) cannot do by itself.

Scripts that refer to the special variables RSTART and RLENGTH can often be simplified by referring to the variables $`, $& and $', provided that they are within the scope of the pattern match that sets them.

The produced perl(1) script may have subroutines defined to deal with awk(1)'s semantics regarding getline and print. Since a2p(1) usually picks correctness over efficiency. it is almost always possible to rewrite such code to be more efficient by discarding the expendable code.

To increase efficiency, you may want to remove the keyword from any return statement that is the last statement executed in a subroutine. A2p(1) catches the most common case, but does not analyze embedded blocks for subtler cases.

ARGV[0] translates to $ARGV0, but ARGV[n] translates to $ARGV[$n]. A loop that tries to iterate over ARGV[0] will not find it.


The a2p(1) utility uses no environment variables.


On success, a2p(1) exits with status 0; otherwise, it exist with a status >0.


It is possible to emulate awk(1)'s behavior in selecting string rather than numeric operations at run time by inspection of the operands. Doing this is inefficient, however; in addition, a2p(1) almost always guesses correctly.

Storage for the awk(1) syntax tree is currently static and can run out.

The version of a2p(1) distributed with 5.003 has known problems with multiple concatenations and redirection.

Concatenations must be in pairs. Therefore,

var="x" "y" "z"
must be expressed as:
var=( "x" "y" ) "z"
to translate. Otherwise a2p(1) prints a message about syntax errors. (This bug did not exist in perl(1) 4.x versions of a2p(1).)

Redirection, such as:

{ print("cat") > "dog" }
will not be translated correctly. You might want to comment out redirection lines and rewrite them in perl(1) directly.


perl(1) [the perl(1) compiler/interpreter]

s2p(1) [sed(1) to perl(1) translator]


Larry Wall <lwall@jpl-devvax.Jpl.Nasa.Gov>