Comportamento di tr -c -d durante l'eliminazione di byte con valori che non sono caratteri

Question

Ho difficoltà a comprendere questo paragrafo dalla sezione "RATIONALE" di http://pubs.opengroup.org/onlinepubs/9699919799/utilities/tr.html.

L'ISO POSIX-2: 1993 standard aveva un opzione -c che si comportava in modo simile per l'opzione -C, ma non hanno fornito le stesse funzionalità della opzione -c specificato nel POSIX.1-2008. Ciò significava che la pratica storica di essere in grado di specificare tr -cd \ 000- \ 177 (che eliminerebbe tutti i byte con il bit più alto impostato) non avrebbe alcun effetto perché, nella locale C , i byte con i valori ottali 200 a ottali 377 non sono caratteri.

Tuttavia, il mio test sul sistema CentOS 6.5 sembra dimostrare che sembra avere un effetto.

$ export LC_ALL=C 
$ export LANG=C 
$ locale 
LANG=C 
LC_CTYPE="C" 
LC_NUMERIC="C" 
LC_TIME="C" 
LC_COLLATE="C" 
LC_MONETARY="C" 
LC_MESSAGES="C" 
LC_PAPER="C" 
LC_NAME="C" 
LC_ADDRESS="C" 
LC_TELEPHONE="C" 
LC_MEASUREMENT="C" 
LC_IDENTIFICATION="C" 
LC_ALL=C 
$ printf "\x41\x42\x81\x82" | od -t x1 
0000000 41 42 81 82 
0000004 
$ printf "\x41\x42\x81\x82" | tr -c -d "\000-\1777" | od -t x1 
0000000 41 42 
0000002 

Il comando tr -c -d "\000-\1777" rimosso il byte con valori \x81 e \x82. Perché il risultato del mio test non è in accordo con ciò che è scritto nelle specifiche?

Answer 1

Poiché si utilizza CentOS, è molto probabile che il comando tr provenga dal pacchetto GNU coreutils. GNU tr non fa (ancora) una distinzione tra il comportamento di -c e -C. Nelle versioni recenti di tr, sia -c sia -C sono opzioni abbreviate equivalenti per l'opzione --complement.

Secondo il GNU documentation for tr:

Attualmente tr completamente supporta solo caratteri a singolo byte. Alla fine supporterà i personaggi multibyte; quando lo fa, l'opzione -C lo farà integrare al set di caratteri, mentre -c lo farà integrare alla serie di valori. Questa distinzione sarà importante solo quando alcuni valori non sono caratteri, e questo è possibile solo nelle versioni locali che utilizzano codifiche multibyte quando l'input contiene errori di codifica.

Ho trovato anche il paragrafo citato dalla specifica POSIX da confusamente formulato ma io sono d'accordo con l'interpretazione di Etan Reisner che “le implementazioni conformi alla versione 1993 della spec sarebbe rotto, ma le implementazioni precedenti (storici) e implementazioni conformi alle specifiche 2008 (e più recenti) funzionerebbero ".

In ogni caso, GNU tr non (ancora) attuare questa parte della specifica POSIX 2008 (cioè, distinguendo tra caratteri e valori) in modo che non può essere utilizzato per il test.

A proposito, si dispone di unridondante nel comando tr -c -d "\000-\1777".