uniq hiba?

Szkriptek: Python, Perl, Bash, ...

Ebben a fájlban (kitömörítés után) elvileg minden sor egyedi: http://web2.osb.hu/z/nincsismetles.txt.bz2
Mégis, a uniq -d több ismételt sorra utal: sort nincsismetles.txt |uniq -d|wc -l
1960

Ha kilistázom a találatokat és rákeresek bármelyikre, akkor csak egy sor adódik. Pl.:
sort nincsismetles.txt |uniq -d|tail -n 9|head -n 1
ZZSZSSPKKPKP
grep ZZSZSSPKKPKP nincsismetles.txt
ZZSZSSPKKPKP

Mitől lehet ez?

  • 5852 megtekintés

( o_O v | 2012. 01. 02., h – 21:47 )

Nincs bent ismetles: 


cat nincsismetles.txt | sort | uniq -c | sort -n

--
1 leszel vagy 0 élő vagy hulla!

( Nyosigomboc v | 2012. 01. 02., h – 22:03 )

sort nincsismetles.txt |uniq -d|wc -l
nalam 0-at ad

--
There are free things in life i'll never understand
Spelling and counting

( egmont | 2012. 01. 02., h – 23:05 )

Milyen rendszered van? Nekem ubuntu 10.04 és mac 10.6.8 alatt is helyesen semmit sem ír ki a uniq -d.

( arrabonus v | 2012. 01. 02., h – 23:20 )

Ubuntu 11.10, 64 bit nálam is 1960 ismétlődést ír.

nyos@hex:/tmp/x$ sort nincsismetles.txt |uniq -d
nyos@hex:/tmp/x$ cat /etc/issue
Ubuntu 11.10 \n \l

nyos@hex:/tmp/x$ uname -a
Linux hex 3.0.0-14-generic #23-Ubuntu SMP Mon Nov 21 20:28:43 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

--
There are free things in life i'll never understand
Spelling and counting

sgyori@hp6730s:/tmp$ sort nincsismetles.txt | uniq -d | wc -l
1960
sgyori@hp6730s:/tmp$ cat /etc/issue
Ubuntu 11.10 \n \l

sgyori@hp6730s:/tmp$ uname -a
Linux hp6730s 3.0.0-14-generic #23-Ubuntu SMP Mon Nov 21 20:28:43 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
sgyori@hp6730s:/tmp$ uniq --version
uniq (GNU coreutils) 8.5
Copyright (C) 2010 Free Software Foundation, Inc.
A licenc GPLv3+: a GNU GPL 3. vagy újabb változata
Ez egy szabad szoftver, terjesztheti és/vagy módosíthatja.
NINCS GARANCIA, a törvény által engedélyezett mértékig.

Írta Richard M. Stallman és David MacKenzie.

Érdekes, nincs egyetlen LC* környezeti változóm sem...

szerk:

Illetve mégis van:

sgyori@hp6730s:/tmp$ locale
LANG=hu_HU.UTF-8
LANGUAGE=
LC_CTYPE="hu_HU.UTF-8"
LC_NUMERIC="hu_HU.UTF-8"
LC_TIME="hu_HU.UTF-8"
LC_COLLATE="hu_HU.UTF-8"
LC_MONETARY="hu_HU.UTF-8"
LC_MESSAGES="hu_HU.UTF-8"
LC_PAPER="hu_HU.UTF-8"
LC_NAME="hu_HU.UTF-8"
LC_ADDRESS="hu_HU.UTF-8"
LC_TELEPHONE="hu_HU.UTF-8"
LC_MEASUREMENT="hu_HU.UTF-8"
LC_IDENTIFICATION="hu_HU.UTF-8"
LC_ALL=

nyos@hex:/tmp/x$ md5sum nincsismetles.txt
0c10ac7317ba7bad8a092e07aa18f767 nincsismetles.txt
nyos@hex:/tmp/x$ sha1 nincsismetles.txt
sha1pass sha1sum
nyos@hex:/tmp/x$ sha1sum nincsismetles.txt
66703e7f95c4098c634c3eb0f6be83879e82f5be nincsismetles.txt
nyos@hex:/tmp/x$ md5sum nincsismetles.txt
0c10ac7317ba7bad8a092e07aa18f767 nincsismetles.txt
nyos@hex:/tmp/x$ uniq --version
uniq (GNU coreutils) 8.5
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Richard M. Stallman and David MacKenzie.
nyos@hex:/tmp/x$ md5sum /usr/bin/uniq /usr/bin/sort
9757a4a7c31467852b9365eff176d5de /usr/bin/uniq
2e82c6bf038780a73b40de1909e4013c /usr/bin/sort

--
There are free things in life i'll never understand
Spelling and counting

Fordítottam magamnak 8.5-ös coreutils ubi 10.04 alá, és ott is jól működnek a programok.

Akinél hibás: érdekes lenne megnézni hogy a sort és a uniq közül melyik a szar, és aztán ubuntunak jelenteni, szerintem ők rontották el. Avagy kézzel fordított coreutils-8.5 csomaggal is kipróbálni. (./configure --prefix=/tmp/C && make && make install && /tmp/C/bin/sort nincsismetles.txt | /tmp/C/bin/uniq -d)

( pinyo_villany | 2012. 01. 03., k – 00:05 )

a csodalatosan implementalt nyelvi funkciok miatt, lehet gettext vagy locales hiba

bugreport, de elotte allitsd at /etc/defaults/locale-sben a nyelvi dolgokat, es teszteld le, vagy sima kornyezeti valtozokent exportalj US beallitast, es nezd meg, hogy ugy rossz-e
___
info

( locsemege v | 2012. 01. 03., k – 00:07 )

bzcat nincsismetles.txt.bz2 | sort | uniq -d | wc -l
0

rpm -qf `which uniq`
coreutils-8.12-2.fc16.x86_64

Fedora 16-on tehát jó.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

( egmont | 2012. 01. 03., k – 00:35 )

Megvan, rájöttem a bibire.

A hu_HU.UTF-8 locale okozza, workaroundnak LC_COLLATE=C.

A probléma az, hogy az ábécérendbe rendező rész a kettősbetűket okosan próbálja meg sorrendbe rakni, és ezt úgy teszi, hogy a "SSZ" kettősbetűt [SZ][SZ]-nek tokenizálja. Csakhogy a "SZSZ" is [SZ][SZ]-ként tokenizálódik, az strcoll() tehát azonosnak tekinti őket.

Régen hegesztettem egy adagot a magyar locale definíción, de erre a problémára nem gondoltam. Végiggondolom hogy mit lehet tenni...

http://hup.hu/node/110267#comment-1397788

Nem lehetne az egesz ilyen hulyeseget kihajitani a francba, es ugy, mint C locale eseten "ertelmesen" rendezni?!

KDE4 is es az osszes linuxos rendszer kiviszi az agyam, amikor a kis es nagybetuk ossze vannak keverve es nem latom elol a nagybetus dolgokat. A masik ilyen, hogy szerintem nem egy script epit az kis es nagybetuk sorrendjere...
___
info

Igazából azt rosszul írtam az imént: nem a sort-ot, hanem a uniq-ot hülyítette meg az, hogy különböző sorokat azonosnak látott. -i kapcsoló esetén strcoll() helyett strcmp()-ot használ valószínűleg, utóbbi nem függ a locale-től. Azt mondjuk nem értem, hogy a uniq mi a rákért használ bármiféle locale-t egyáltalán bármikor :)

Az új helyesírási szabályzat kapcsán átnéztem, hogy jó-e ami most a glibc-ben van, és most vettem észre, hogy az előző „javításom” behozott egy csúnya hibát. Meg mások is elrontottak közben ezt-azt; a magyar locale definícióban is és a strcoll() implementációjában is, ááááá!!!

A https://sourceware.org/bugzilla/show_bug.cgi?id=18934 címen található a javítás, fene tudja mikor fogják alkalmazni, remélem viszonylag hamar. Immár unittesteket is csináltam, szóval remélhetőleg ha ezt egyszer berakják akkor többé már nem romlik el.

Plusz az itteni eredeti probléma megoldására is tettem egy általánosabb javaslatot: https://sourceware.org/bugzilla/show_bug.cgi?id=18927

(Függetlenül attól, hogy mindent le lehet kódolni a szabály követéséhez, innen üzenném annak a szakbarbár nyelvi akadémikusnak, aki kiagyalta, hogy milyen ésszerű is volna a mérnöki szabványokkal ellenkezve a magyarban a-zA-Z sorrendiséget bevezetni, hogy a XXI. században inkább a p*csével foglalatoskodjék.)

Mint fentebb (vagy lentebb) olvashatod, más nyitotta ki a zsebkésemet. Amellett lehet érvelni, hogy e=é, de amellett, hogy szécsi legyen előbb, mint Szécsi, csak egy érv szólhat: juszt se legyen igaza a karaktertáblázatokat gyártó mihasznáknak, majd mi megmutatjuk nekik, milyen genya egeret tud szülni évtizednyi vajúdással pár hegy.

Udvariassági szempontból jobb ötletnek tartottam volna, ha a nagybetű kerül elölre. De a karaktertáblázat – miután eleve rakat egyéb szabály van, amelyek úgyis sokkal bonyolultabb algoritmust igényelnek, mint a karakterek kódjainak összehasonlítását – nem tök lényegtelen?

Mondhatjuk, hogy tök lényegtelen - mint írtam: bármi lekódolható; ez is.

Viszont szót ejtettem a szakbarbarizmusról is. Szép, hogy kitekintéssel vannak a modern élet velejáróira, és gyorsan fájlt alkotnak a file-ból és bájtot a byte-ból, de ha esetleg megkérdeznék az MTA ügyeletes helpdeszkesétől, hogy ha felvetődne még ilyen-olyan ötletük, szakmailag mit gondolna róla, az tán még szimpatikusabb volna.
Ahogyan én is előkapok egy szótárat/lexikont, ha valamilyen szó megfog - pedig senki se kényszerít pisztollyal, csak az igényesség motivál.

'Case insensitive a rendezés, kivéve ha semmi más nem dönt.'

Ésszerű... pardon: észszerű, amit írsz, ezért aztán juszt is máshogy van már kodifikálva:

'A betűrendbe sorolás szempontjából nem teszünk különbséget a kis- és a nagybetűk között.

Ha azonban két besorolandó egység között csupán ebben a vonatkozásában van különbség, akkor a kis kezdőbetűs szó megelőzi a nagy kezdőbetűst, például: jácint, Jácint, szűcs, Szűcs, opera, Opera, viola, Viola.”'

http://index.hu/tudomany/2015/06/26/az_uj_helyesirasi_szabalyzat_csak_m…

Ezt nevezem én a kapjákbe minősített esetének, még ha zárójelben is dörmögök.

Konkretan az, hogy ez eddig az elet majd' minden teruleten forditva uzemelt. Ha mar annyira olyan szabalyzatot akartak hozni, ami koveti a mindennapi nyelvhasznalat sajatossagait, akkor itt is figyelembe vehettek volna ezt a szempontot. Engem rettenetesen zavar az, hogy az MTA veri a mellet, hogy most milyen jol igazodtak a nepi nyelvhez, de azert elrejtenek ilyen kis buzbombakat a szovegben.
--
Blog | @hron84
Üzemeltető macik

" but "cscs" (not used in valid Hungarian words, but might occur in text files anyways)"
Azert ez igy ebben a formaban nem igaz, mert a kulcscsomo egy teljesen valid Hungarian word, ugyanakkor megsem lehet osszevonni hosszu cs-be a ket cs-t, mert osszetett szo szohataran ilyet tilos.

Just FYI.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( -Mr- | 2012. 01. 03., k – 01:13 )

Ubuntu

uname -srvmpio
Linux 3.0.0-14-generic #23-Ubuntu SMP Mon Nov 21 20:28:43 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

sort nincsismetles.txt |uniq -d | wc -l
1960

sort nincsismetles.txt |uniq -dw 11 | wc -l
1720

Érdekes hogy ha csak az első 11 karaktert vizsgáljuk úgy kevesebb találatot hoz mintha az egész sort néznénk.

sort nincsismetles.txt |uniq -di | wc -l
0

Ha beállítom hogy vegye egyformának a kisbetűt és a nagybetűt, akkor jó értéket köp vissza az uniq...