Range do comando cut in unix

Question

Estou tentando fazer um script de shell, quero cortar uma string usando o comando unix 'cut', da seguinte maneira:

namecmpaux=$(echo $namecmp |cut -c0-19)

Mas quando eu corro, o shell me diz o seguinte erro:

cut: fields and positions are numbered from 1 
Try 'cut - help 'for more information.

Lembro-me de ter usado anteriormente o comando 'cut' usando zero como a posição limite inferior, mas agora me diz que o comando deve começar em 1. Por quê ?, depende do sistema operacional? SunOS usado anteriormente e agora estou usando o Ubuntu 12.04

    

Answer 1

Não, é o mesmo em todas as implementações de cut . Os números começam em um, é apenas o Solaris não reclamará se você fornecer 0 e o tratará como 1. Ambos 0 e 1 significa o primeiro caractere e 2 significa o segundo caractere:

$ echo test | cut -c 0-2
te
$ echo test | cut -c 1-2
te

busybox cut ou cut incorporado em ksh93 também não se queixam. O GNU cut apenas tenta ser útil em dizer que você provavelmente não tem a idéia correta sobre o que é o primeiro índice.

Uma diferença real é que GNU e busybox cut (pelo menos a partir de 2014-03-27), contam em bytes para -c , enquanto Solaris ou ksh cut contam em caracteres (como requer POSIX) .

$ echo 'Stéphane' | cut -c 1-4
Sté
$ echo 'Stéphane' | busybox cut -c 1-4
Sté
$ echo 'Stéphane' | ksh -c 'command /opt/ast/bin/cut -c 1-4'
Stép

(em uma localidade UTF-8, é (U + 00E9) leva 2 bytes)

    

Answer 2

Sim, isso pode, de fato, depender do sistema operacional (ou depender de quem escreveu sua versão de cut ).

Se você der uma olhada em man cut , verá que cut do coreutils contagens de bytes, caracteres e campos do GNU de 1:

Use one, and only one of -b, -c or -f. [...] Each range is one of:
      N      N'th byte, character or field, counted from 1

Mais uma vez, isso pode diferir em um sistema diferente se seus mantenedores decidiram usar uma implementação de cut diferente do GNU, então é melhor estar seguro e dar uma olhada na página do manual para ter certeza.

    

Answer 3

Até trabalhou antes no Linux. Eu fui mordido por ele (No Debian, depois de uma atualização do pacote coreutils que contém o comando cut) e achei este bug.

É um bug no coreutils:

link

Alguém quebrou a compatibilidade com a finalidade e ninguém a corrigiu. Costumava ser assim 0 também estava bem e tratado como 1. Agora 0 produz um erro. Portanto, todos os scripts que dependem desse comportamento estão corrompidos e devem ser alterados.