Início / unix / Perguntas / 468966
Accepted
phg
Asked: 2018-09-14 23:26:39 +0800 CST

Contar linhas com mais de 80 colunas, levando em consideração as guias corretamente

  • 772

Para contar linhas com mais de 80 colunas estou, atualmente, usando este comando:

$ git grep -h -c -v '^.\{,80\}$' **/*.{c,h,p{l,y}} \
    |awk 'BEGIN { i=0 } { i+=$1 } END { printf ("%d\n", i) }'
44984

Infelizmente, o repositório usa guias para recuar, portanto, o greppadrão é impreciso. Existe alguma maneira de ter as regexguias de tratamento na largura padrão de 8 caracteres, como wc -Lacontece?

Para os propósitos desta pergunta, podemos supor que os colaboradores foram disciplinados o suficiente para recuar consistentemente, ou que eles têm git commitganchos em vez de disciplina.

Por motivos relacionados ao desempenho, prefiro uma solução que funcione dentro git-grep(1)ou talvez outra grepferramenta, sem pré-processamento de arquivos .

grep

4 respostas

  1. Pré-processe os arquivos canalizando-os através de expand. O expandutilitário expandirá as guias adequadamente (usando as paradas de tabulação padrão a cada 8 caracteres).

    find . -type f \( -name '*.[ch]' -o -name '*.p[ly]' \) -exec expand {} + |
awk 'length > 80 { n++ } END { print n }'
    • 12

  2. GNU wc -Lnão trata TABs como 8 caracteres, ele trata TABs como eles seriam exibidos em um terminal com paradas de TAB a cada 8 colunas, então teria uma "largura" variando de 1 a 8 caracteres, dependendo de onde eles são encontrados na linha . wc -Ltambém considera a largura de exibição de outros caracteres (se eles têm 0, 1 ou 2 colunas de largura) e também processa \fe \r"corretamente".

    $ printf 'abcde\t\n' | wc -L
8

    Aqui, você pode usar expand(que por padrão também assume paradas de tabulação a cada 8 colunas, embora você possa alterá-lo com opções) para expandir essas TABs para espaços:

    git grep -h '' ./**/*.{c,h,p{l,y}} | expand | tr '\f\r' '\n\n' | grep -cE '.{81}'

    (convertendo os CRs (que quando enviados para um terminal movem o cursor de volta ao início da linha) e FFs (que alguns dispositivos de exibição entendem como quebra de página) para LF para obter o mesmo comportamento que wc -L, mas ignorando os outros que de qualquer forma não podemos dizer que influência eles terão na largura da tela).

    Isso abrange TABs, mas não caracteres de largura simples ou dupla. Observe que a implementação GNU de expandatualmente não expande TABs corretamente se houver caracteres de vários bytes (muito menos de largura zero ou largura dupla).

    $ printf 'ééééé\t\n' | wc -L
8
$ printf 'ééééé\t\n' | expand | wc -L
11

    Observe também que ./**/*.{c,h,p{l,y}}, por padrão, ignoraria arquivos ocultos ou arquivos em diretórios ocultos. À medida que a expansão do brace se expande para vários globs, você também obteria erros (fatal with zshor bash -O failglob) se um desses globs não corresponder.

    Com zsh, você usaria ./**/*.(c|h|p[ly])(D.)que é um glob e onde Dinclui arquivos ocultos e .restringe a arquivos regulares .

    Para uma solução que leva em consideração a largura real dos caracteres (supondo que todos os arquivos de texto sejam codificados na codificação de caracteres da localidade), você pode usar:

    git grep -h '' ./**/*.(c|h|p[ly])(.) | tr '\r\f' '\n\n' |
  perl -Mopen=locale -MText::Tabs -MText::CharWidth=mbswidth -lne '
    $n++ if mbswidth(expand($_)) > 80;
    END{print 0+$n}'

    Observe que, pelo menos em sistemas GNU, mbswidth()considera os caracteres de controle como tendo uma largura de -1e 1 para expand(). Assumimos que nenhum caractere de controle diferente de CR, NL, TAB, FF é encontrado nos arquivos.

    • 10
  3. Best Answer

    Se pudermos presumir pelo seu comentário que os caracteres de tabulação aparecerão apenas no início das linhas, podemos contar alternativas para um mínimo de 80 caracteres.

    • Sem guias, pelo menos 81 caracteres
    • Uma guia, pelo menos 73 caracteres
    • Duas guias, pelo menos 65 caracteres
    • etc.

    A confusão resultante é a seguinte, com sua awkdeclaração somando as contagens de linhas individuais para fornecer um total geral

    git grep -hcP '^(.{81,}|\t.{73,}|\t{2}.{65,}|\t{3}.{57,}|\t{4}.{49,}|\t{5}.{41,}|\t{6}.{33,}|\t{7}.{25,}|\t{8}.{17,}|\t{9}.{9,}|\t{10}.)' **/*.{c,h,p{l,y}} |
    awk '{ i+=$1 } END { printf ("%d\n", i) }'
    • 8

  4. Uma solução com ex (de vi ). Embora lento.

    Como o vi é capaz de processar corretamente dados UTF-8:

    Ele pode expandir as guias para espaços, contar os caracteres de controle como 1, processar \r \t \f \vcorretamente e também processar a maioria dos valores UNICODE válidos . Incluindo acentos compostos (NKC) e decompostos (NKD) e caracteres do cirílico, árabe, grego, chinês e muitos outros.

    $ cat script.sh
#!/bin/bash --

declare -i count=0

for i do
    # Set ex script in one variable
    a='set expandtab        "       Expand tabs to spaces
       r '"$i"'             "       Read original file
       g/^.\{,80\}$/d       "       Remove all lines shorter than the value used
       wq                   "       Quit ' 

    o=outfile; :>"$o"           # Clean output file
    ex -s "$o" <<<"$a"          # process lines in $i file
    count+=$(wc -l <"$o")       # count and accumulate number of lines.
done

echo "$count"

    Chame o script como:

    $ script.sh     **/*.{c,h,p{l,y}}
44984
    • 1

relate perguntas