seqüência de escape ANSI ^ [[K processado por menos -R mas não mais

Question

Estou escrevendo um wrapper em torno de ack para procurar código localmente com algumas linhas adicionais de contexto canalizadas para um pager.

Aqui está o script do wrapper ackc . Entre os diferentes exemplos, estarei variando o que é passado para ack como --pager .

#!/bin/sh

ack -C 20 -i \
    --pager=most \
    --heading \
    --break \
    --color \
    --show-types \
    "$@"

Com less (sem o -R) como o pager, quase todas as seqüências de escape são renderizadas usando a notação de circunflexo (não sei o que é chamado. ^[ é a exceção. Ela é renderizada como ESC com cores de fundo invertidas (cores não reproduzidas aqui).

Aqui está uma amostra da saída (produzida por ackc com --pager=less e variáveis de ambiente como LESS , LESSPIPE etc desmarcadas)

ESC[1;32m.local/lib/python2.7/site-packages/markupsafe/_speedups.cESC[0m
...
ESC[1;33m19ESC[0m:#define PY_SSIZE_T_MAX ESC[30;43mINTESC[0m_MAXESC[0mESC[K
ESC[1;33m20ESC[0m:#define PY_SSIZE_T_MIN ESC[30;43mINTESC[0m_MINESC[0mESC[K

A sequência de escape importante aqui é a sequência ^[[K no final de cada linha que contém um item realçado. Ele é tratado apropriadamente por less -R .

.local/lib/python2.7/site-packages/markupsafe/_speedups.c
...
19:#define PY_SSIZE_T_MAX INT_MAX
20:#define PY_SSIZE_T_MIN INT_MIN

most , no entanto, não parece lidar muito bem com isso.

.local/lib/python2.7/site-packages/markupsafe/_speedups.c
1-/**
...
19:#define PY_SSIZE_T_MAX INT_MAX^[[K
20:#define PY_SSIZE_T_MIN INT_MIN^[[K

Ele passa pela sequência ^[[K como está.

Esta sequência é CSI (n) K -- EL -- Erase in Line . Quando não recebe argumentos, apaga até o final da linha. Presumivelmente, isso é necessário para limpar os bits de dispersão da cor de fundo se o termo correspondente aparecer no final da linha.

Existe uma razão pela qual most não entende essa sequência? Posso configurá-lo para processá-lo corretamente?

    

Answer 1

o comportamento da maioria é codificado. O código-fonte tem vários fragmentos como este para análise após um caractere de escape ser recebido:

     if ((ch == 033) && (Most_V_Opt == 0))
       {
      while ((ch == 033)
         && (0 == most_parse_color_escape (&b, e, NULL))
         && (b < e))
        ch = *b++;
       }

Basicamente, ele diz que se encontrar um caractere de escape ( 033 ) e a opção -V não estiver definida, procure sequências de escape de cor ANSI.

Todas as operações de limpeza começam com um caractere de escape, então a maioria não fará o que for solicitado.

A propósito, vejo que Davis fez uma mudança alguns dias atrás como uma solução alternativa. Em última análise, isso estará em uma versão empacotada ...

Author: John E. Davis   2018-07-11 06:26:02
Committer: John E. Davis   2018-07-11 06:26:02
Parent: 97befd7b984520e80475bb1cb857b35650755a15 (pre5.1-20: Added support for Home/End keys)
Branches: master, remotes/origin/master
Follows: 
Precedes: 

    pre5.1-21: Added a work-around for programs that try colorize the output using the clear-to-end-of-line escape sequence (ESC[K) without regard for the value of isatty(fileno(sdout)).

+21. src/line.c: Added a work-around for programs that try colorize the
+    output using the clear-to-end-of-line escape sequence (ESC[K)
+    without regard for the value of isatty(fileno(sdout)).  Most will
+    ignore ESC[K unless invoked with -v.