15

I have some old code from 2003 which uses -t option for uniq command. It throws an error since that option is probably not supported anymore.

Here's the piece which uses the command:

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

What did that option do back then? What can I substitute that command with?

13

The only reference I could find to -t is in this patch on a GNU mailing list, which contains among other clues, this:

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

This apparently was a GNU extension but no longer in use. It appears to allow selecting a delimiting character for fields other than spaces or tabs. Try replacing

uniq -t ':' -f 1 | \

with

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

which will replace : with spaces which uniq recognizes the field separator.

  • I would drop the g from sed, since only the first field is skipped. At least one colon is needed for the last line to work (hopefully not the first). Still no guarantee it will work though (any of the first fields may contain whitespace) – Graeme Feb 1 '14 at 15:02
  • @Graeme Good point, edited. – casey Feb 1 '14 at 15:23
  • In Debian, coreutils 5.2.1 indeed had such a patch applied, and apparently it was removed in 5.93-1, that is, in November 2005. – user2719058 Feb 2 '14 at 0:07
4

Given the man entry for the -f option:

-f, --skip-fields=N

         avoid comparing the first N fields

I think it is fairly safe to assume that -t specifies the field separator (this is also the case for sort in the line above). The combination of the two options would make uniq only operate on the part of the line following the first colon.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.