Bash
Il comando di taglio

Il comando di cut è un modo rapido per estrarre parti di righe di file di testo. Appartiene ai più vecchi comandi Unix. Le sue implementazioni più popolari sono la versione GNU trovata su Linux e la versione di FreeBSD che si trova su MacOS, ma ogni gusto di Unix ha il suo. Vedi sotto per le differenze. Le righe di input vengono lette da stdin o da file elencati come argomenti sulla riga di comando.

1. Differenze di sintassi

Le lunghe opzioni nella tabella sopra sono supportate solo dalla versione GNU.

2. Nessun personaggio riceve un trattamento speciale

FreeBSD cut (che viene fornito con MacOS, ad esempio) non ha l' --complement e, nel caso degli intervalli di caratteri, si può usare invece il comando colrm :

  $ cut --complement -c3-5 <<<"123456789"
  126789

  $ colrm 3 5 <<<"123456789"
  126789

Tuttavia, c'è una grande differenza, perché colrm tratta i caratteri TAB (ASCII 9) come tabulazioni reali fino al prossimo multiplo di otto, e i backspaces (ASCII 8) come -1 di larghezza; al contrario, cut considera tutti i caratteri come una colonna larga.

  $ colrm  3 8 <<<$'12\tABCDEF' # Input string has an embedded TAB
  12ABCDEF

  $ cut --complement -c3-8 <<<$'12\tABCDEF'
  12F

3. (Ancora no) Internazionalizzazione

Quando cut è stato progettato, tutti i personaggi sono stati a lungo un byte e l'internazionalizzazione non era un problema. Quando si scrivono sistemi con caratteri più ampi, la soluzione adottata da POSIX è stata quella di eseguire il diting tra il vecchio switch -c , che dovrebbe mantenere il suo significato di selezione dei caratteri, indipendentemente dal numero di byte, e di introdurre un nuovo switch -b che dovrebbe selezionare i byte, indipendentemente dalla codifica dei caratteri corrente. Nelle implementazioni più popolari, -b stato introdotto e funziona, ma -c funziona ancora esattamente come -b e non come dovrebbe. Ad esempio con GNU cut :

^{Sembra che il filtro antispam di SE inserisca in blacklist testi inglesi con caratteri kanji isolati. Non sono riuscito a superare questa limitazione, quindi i seguenti esempi sono meno espressivi di quanto potrebbero essere.}

  # In an encoding where each character in the input string is three bytes wide,
  # Selecting bytes 1-6 yields the first two characters (correct)
  $ LC_ALL=ja_JP.UTF-8 cut -b1-6 kanji.utf-8.txt
  ...first two characters of each line...
  

  # Selecting all three characters with the -c switch doesn’t work.
  # It behaves like -b, contrary to documentation.
  $ LC_ALL=ja_JP.UTF-8 cut -c1-3 kanji.utf-8.txt
  ...first character of each line...

  # In this case, an illegal UTF-8 string is produced.
  # The -n switch would prevent this, if implemented.
  $ LC_ALL=ja_JP.UTF-8 cut -n -c2 kanji.utf-8.txt
  ...second byte, which is an illegal UTF-8 sequence...

Se i tuoi personaggi sono al di fuori dell'intervallo ASCII e vuoi usare cut , dovresti sempre essere consapevole della larghezza dei caratteri nella tua codifica e usare di conseguenza -b . Se e quando -c inizia a funzionare come documentato, non dovrai modificare i tuoi script.

4. Confronti di velocità

i limiti del cut hanno persone che dubitano della sua utilità. In effetti, la stessa funzionalità può essere raggiunta con utility più potenti e più popolari. Tuttavia, il vantaggio di cut è la sua prestazione . Vedi sotto per alcuni confronti di velocità. test.txt ha tre milioni di righe, ognuna con cinque campi separati dallo spazio. Per il test awk , mawk stato usato mawk , perché è più veloce di GNU awk . La shell stessa (ultima riga) è di gran lunga il peggiore. I tempi indicati (in secondi) sono ciò che il comando time fornisce in tempo reale .

^{(Giusto per evitare equivoci: tutti i comandi testati hanno dato lo stesso risultato con l'input dato, ma ovviamente non sono equivalenti e darebbero output diversi in situazioni diverse, in particolare se i campi fossero delimitati da un numero variabile di spazi)}

5. Pagine man referenziali

• OpenGroup
• GNU
• FreeBSD