uniq hiba?

 ( szz | 2012. január 2., hétfő - 22:31 )

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?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Nincs bent ismetles:

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

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

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

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

Rossz fájlt nézel?

Amikor 1960-at ír ki, akkor vedd ki a wc -l részét.

$ wget -q http://web2.osb.hu/z/nincsismetles.txt.bz2
$ bunzip2 nincsismetles.txt.bz2
$ sha1sum nincsismetles.txt
66703e7f95c4098c634c3eb0f6be83879e82f5be nincsismetles.txt
$ sort nincsismetles.txt | uniq -d | wc -l
0

--
joco voltam szevasz

32 vagy 64 bit?
___
info

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

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

< ironia >az stable mar, nem?!< /ironia >
___
info

Stabilan 1960-at ad :-)

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.

export | grep LC*
___
info

Reszemrol en_DK.utf8, de ennek nem hiszem, hogy lenne jelentosege, nem olyan a file (csak \n es A-Z van benne).

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

É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

A file látszólag ugyanaz:

sgyori@hp6730s:/tmp$ md5sum nincsismetles.txt
0c10ac7317ba7bad8a092e07aa18f767 nincsismetles.txt
sgyori@hp6730s:/tmp$ sha1sum nincsismetles.txt
66703e7f95c4098c634c3eb0f6be83879e82f5be nincsismetles.txt

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)

Nálam is működik, ahogy kell neki:
Ubuntu 11.10
Linux 3.0.0-14-generic #23-Ubuntu SMP Mon Nov 21 20:28:43 UTC 2011 x86_64

$ sort nincsismetles.txt | uniq -d | wc -l
0

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

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

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

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

De lehetne. export LC_COLLATE=C. Egészen pontosan erre való.

http://sourceware.org/bugzilla/show_bug.cgi?id=13547

Ubuntun a /usr/share/i18n/locales/hu_HU fájlra rá lehet húzni a patchet, majd locale-gen hu_HU.UTF-8

Patch használva

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

Most már jó.
De nem értem hogy korábban a "-i" kapcsolóval mért hozott az uniq mégis jó eredményt?

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 :)

man uniq szerint

...
Note: 'uniq' does not detect repeated lines unless they are adjacent. You may want to sort the input first, or use `sort -u' without `uniq'.
Also, comparisons honor the rules specified by `LC_COLLATE'.
...

Köszönöm a workaroundot s a témára szánt minden erőfeszítést!

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.)

+végtelen :D

ó je :) Arról nem is beszélve hogy milyen nehéz a helyesírási szabályokkal nem teljesen up-to-date usernek elmagyarázni hogy a rendszer bizony helyesen működik.

--
Gábriel Ákos
http://ixenit.com

Ööö... mivan? Nem értelek. Nem a-zA-Z a sorrend. Case insensitive a rendezés, kivéve ha semmi más nem dönt.

Nyilván nem olvasta el az egészet, és arra a (néha valóban bosszantó) nyelvtani szabályra asszociált a címből, hogy az a/á, e/é egyenértékű névsorilag, így pl. a Gezer-t megelőzi a Gérecs. De itt, @lx, ssz, szsz témáról van szó. :-)

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_mismasolas/

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

Elárulnád azt is, hogy konkrétan mi a bajod vele?

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

Azon felül, hogy semmi okuk nem volt rá a farokhosszúsági versenyen való előnyszerzésen kívül? Tkp. semmi. Kívánok nekik sok erőt és fantáziát az efféle korszakalkotásokhoz a jövőben is!

Hát erre sajna majd' 2 évet várni kellett, de a vadiúj glibc-2.26-ba végre bekerült a javítás javítása is :)

:-D

A most megjelent glibc-2.16 javítja a hibát.

" 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

-- dupe --

Jogos. Nevermind :)

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...