xlsatoms
Lista todos os atoms que o servidor X conhece, do PRIMARY predefinido, número 1, aos milhares de nomes que os clientes de hoje internaram — e que o servidor nunca esquece.
Os atoms são o jeito que o protocolo X tem de não enviar strings: um nome é internado uma vez com InternAtom e ganha um número de 32 bits, usado depois em propriedades, seleções e ClientMessage. O xlsatoms de Jim Fulton, de 1989, percorre a tabela com GetAtomName do número 1 em diante até o servidor responder com um erro, imprimindo número e nome. Os primeiros 68 são fixados pelo protocolo e idênticos em todo servidor — PRIMARY é 1, ATOM é 4, WM_COMMAND é 34, WM_CLIENT_MACHINE é 36 e WM_TRANSIENT_FOR é 68 —, então os clientes não precisam perguntar por eles; depois vem tudo o que qualquer cliente criou desde que o servidor subiu, na ordem em que aconteceu. -range 60-70 escolhe um intervalo, -name _NET_WM_PID faz uma consulta a partir do shell e informa um erro se o atom não existir, e -format molda a saída com sintaxe de printf.
A lista é um corte arqueológico. O protocolo básico não tem requisição para apagar um atom, então todo nome vive até o servidor reiniciar, tenha o cliente que o criou sumido ou não semanas atrás. Num desktop comum, mais ou menos uma semana de uptime rende um par de milhares de linhas, com os nomes GDK_ e _NET_ costumando ser os dois maiores grupos, e dá para ler quais toolkits, gerenciadores de janelas e extensões passaram por ali. Isso faz do xlsatoms a ferramenta para caçar vazamentos de atoms: um programa que interna um nome novo e único por janela ou por tooltip enche a tabela do servidor até alguém estranhar por que o X está comendo memória, e um xlsatoms | wc -l antes e depois entrega o culpado em um minuto.