
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 cut
as 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 0
e 1
ali significam o primeiro caractere e 2
significam o segundo caractere:
$ echo test | cut -c 0-2
te
$ echo test | cut -c 1-2
te
busybox
cut
ou o cut
embutido ksh93
também não reclama. O GNU cut
apenas 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 cut
contam 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 cut
do 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 cut
diferente 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.