Faixa do comando cut no unix

Faixa do comando cut no unix

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

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

Mas quando executo o shell me informa 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 'cortar' usando zero como posição limite inferior, mas agora me diz que o comando deve começar em 1. Por quê? Depende do sistema operacional? usei anteriormente o SunOS e agora estou usando o Ubuntu 12.04

Responder1

Não, é o mesmo em todas cutas implementações. Os números começam em um, só que o Solaris não reclamará se você fornecer 0 e o tratará como 1. Ambos 0e 1ali significam o primeiro caractere e 2significam o segundo caractere:

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

busybox cutou o cutembutido ksh93também não reclama. O GNU cutapenas tenta ser útil dizendo que você provavelmente não tem a ideia certa sobre qual é o primeiro índice.

Uma diferença real, porém, é que GNU e busybox cut(pelo menos a partir de 27/03/2014) contam em bytes para -c, enquanto Solaris ou ksh cutcontam em caracteres (conforme exigido pelo 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) ocupa 2 bytes)

Responder2

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

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

Use um e apenas um de -b, -c ou -f. [...] Cada intervalo é um dos seguintes:
      N      N'ésimo byte, caractere ou campo, contado a partir de 1

Novamente, isso pode ser diferente em um sistema diferente se seus mantenedores decidirem usar uma implementação cutdiferente da GNU, então é melhor estar seguro e dar uma olhada na página de manual para ter certeza.

Responder3

Até funcionou antes no Linux. Fui mordido por ele (no Debian, após uma atualização do pacote coreutils que contém o comando cut) e encontrei esse bug.

É um bug no coreutils:

https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/211262

Alguém quebrou a compatibilidade com versões anteriores de propósito e ninguém consertou. Costumava ser assim que 0 também estava bom e era tratado como 1. Agora 0 produz um erro. Portanto, todos os scripts que dependem deste comportamento estão quebrados e devem ser alterados.

informação relacionada