Em ordem decrescente de velocidade (em um sistema GNU em uma localidade UTF-8 e em entrada ASCII) de acordo com meus testes:
grep '.\{80\}' file
perl -nle 'print if length$_>79' file
awk 'length>79' file
sed -n '/.\{80\}/p' file
Exceto para as implementações perl ((ou awk / grep / sed (como mawk ou busybox) que não suportam caracteres de vários bytes), isso conta o comprimento em termos do número de caracteres (de acordo com a configuração LC_CTYPE da localidade) em vez de bytes .
Se houver bytes na entrada que não fazem parte de caracteres válidos (o que acontece às vezes quando o conjunto de caracteres do código de idioma é UTF-8 e a entrada está em uma codificação diferente), dependendo da implementação da solução e da ferramenta , esses bytes serão contados como 1 caractere ou 0 ou não corresponderão a . .
Por exemplo, uma linha que consiste em 30 a sa 0x80 byte, 30 b s, um byte 0x81 e 30 UTF-8 é s (codificado como 0xc3 0xa9), em uma localidade UTF-8 não corresponderia a .\{80\} com GNU grep / sed (como esse byte autônomo 0x80 não corresponde a . ), teria um comprimento de 30 + 1 + 30 + 1 + 2 * 30 = 122 com perl ou mawk , 3 * 30 = 90 com gawk .
Se você quiser contar em termos de bytes, corrija a localidade para C com LC_ALL=C grep/awk/sed... .
Isso teria todas as 4 soluções considerando que a linha acima contém 122 caracteres. Exceto nas ferramentas perl e GNU, você ainda tem problemas potenciais para as linhas que contêm caracteres NUL (0x0 byte).
¹ o comportamento perl pode ser afetado pela variável de ambiente PERL_UNICODE , embora