Qu'a fait `uniq -t`?

J'ai un vieux code de 2003 qui utilise l' -toption de uniqcommande. Il génère une erreur car cette option n'est probablement plus prise en charge.

Voici la pièce qui utilise la commande:

egrep -n "{ IA32_OP" ia32-decode.c | \
    awk '{ print $1 $3 $4 }' | \
    sort -t '(' +1 | \
    uniq -t ':' -f 1 | \
    sed 's/\(.*\)\:IA32_OP(\(.*\)),/#define IA32_OP_\2 \1/g' >> ia32_opcodes.h

Qu'est-ce que cette option faisait à l'époque? Avec quoi puis-je remplacer cette commande?

uniq

— Babken Vardanyan
source

Voici la source BTW: web.archive.org/web/20040217131820/http://www.team-teso.net/…

— Babken Vardanyan

Selon man uniq, -f 1évite de comparer le premier champ. J'en déduirais -t ':'que cela -test censé changer le séparateur de champ des blancs en :.

— Martin von Wittich

Peut-être pertinent: stackoverflow.com/questions/10546337/… Peut-être -tqu'une option spécifique à Debian a été supprimée plus tard?

— Martin von Wittich

Peut-être pertinent: bugs.debian.org/cgi-bin/bugreport.cgi?bug=117016

— Martin von Wittich

Je me suis toujours demandé pourquoi uniqn'avait pas le même -tet en -ktant que tri ou pourquoi le tri n'avait pas toutes les fonctionnalités de uniqincorporé (car il en a maintenant -u). Ceux -w/ -f/ -sde GNU uniq n'ont pas de sens. Pourquoi ne pourraient-ils pas utiliser la même syntaxe que sort.

— Stéphane Chazelas

Réponses:

La seule référence que j'ai pu trouver -test dans ce correctif sur une liste de diffusion GNU, qui contient entre autres indices, ceci:

+  -t, --separator=S     use a character in string S as field separator\n\

Il s'agissait apparemment d'une extension GNU mais elle n'est plus utilisée. Il semble permettre de sélectionner un caractère de délimitation pour les champs autres que les espaces ou les tabulations. Essayez de remplacer

uniq -t ':' -f 1 | \

avec

sed 's/:/ /' | \
uniq -f 1 | \

qui remplacera :par des espaces qui uniq reconnaît le séparateur de champ.

— casey
source

Je laisserais tomber gfrom sed, car seul le premier champ est ignoré. Au moins un deux-points est nécessaire pour que la dernière ligne fonctionne (si tout va bien pas la première). Toujours aucune garantie que cela fonctionnera cependant (l'un des premiers champs peut contenir des espaces)

— Graeme

@Graeme Bon point, édité.

— casey

Dans Debian, coreutils 5.2.1 avait en effet appliqué un tel patch, et il a apparemment été supprimé en 5.93-1, c'est-à-dire en novembre 2005.

— user2719058

Étant donné l' manentrée pour l' -foption:

-f, --skip-fields = N

         avoid comparing the first N fields

Je pense qu'il est assez sûr de supposer que -tspécifie le séparateur de champ (c'est également le cas sortdans la ligne ci-dessus). La combinaison des deux options ne ferait uniqque fonctionner sur la partie de la ligne suivant le premier deux-points.

— Graeme
source