[PATCH, RFC] Interpretation of TTY audit logs

Hello, the attached patch implements TTY audit log data interpretation: it turns data=627F6361740D6964202D610D6C73202D6C202F626F090D10202D6C72740D0110011B661B640B202D6C7274156364202D1B7F6364207E6D69096C69096F090D6C730D126370201B3E63640D6C730D726D20627A496D09757F0D6364202D0D12637020051B7F626F09766D6C0937090D6364202F626F090D126D6B696E6974720D04 into "b",backspace,"cat",ret,"id -a",ret,"ls -l /bo",tab,ret,^P," -lrt",ret,^A,^P,^A,esc,"f",esc,"d",^K," -lrt",^U,"cd -",esc,backspace,"cd ~mi",tab,"li",tab,"o",tab,ret,"ls",ret,^R,"cp ",esc,">cd",ret,"ls",ret,"rm bzIm",tab,"u",backspace,ret,"cd -",ret,^R,"cp ",^E,esc,backspace,"bo",tab,"vml",tab,"7",tab,ret,"cd /bo",tab,ret,^R,"mkinitr",ret,^D (Usually, bash would be patched to emit an USER_TTY record for each command line, and each USER_TTY record causes emitting a TTY record for the collected data. This record was created without a patched bash, so it contains all commands in the session.) So far the patch supports only a few basic control sequences (arrow and function keys with no modifiers). Before I add many more, I have a few questions: * Is it OK to hard-code the control sequences in the library? Would it be preferable store them in a separate file instead, letting end-users add or modify control sequences? * How to share the code with src/ausearch-report.c? Copying the code is ugly; reasonable options are * move the data interpretation code to libaudit (either only TTY audit interpretation, or all of it) * link ausearch to libauparse * Is there any reason to support conflicting terminal types (e.g. something other than vt100-like terminals)? Are there conflicts in the control sequences emitted by commonly used terminal emulators? Thank you, Mirek