• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    DELVITLinux pro zacatecniky a obycejne uzivatele (NO FLAMES!)
    KOC256
    KOC256 --- ---
    E2E4:
    Uz na to koukam jen z postele. Zitra to zkusim. Ale vypada to ze tim poradi to nebude kryz i “ls” to vypisuje jako cg ch ci cj. Tak predpokladam ze split vznikal stejne. Ale tak ten “cat” mohu zkusit i z prohozenym ch. Jen mi to bezi na nasu tak pak na vysledek cekam krapet dele. Mozna se zeptam jinak.

    Kdyz MD5 musi prechroustat cely soubor, tak cim porovnat puvodni zalohu bit po bitu oproti streamu
    “cat zaloha_part_* | ??? zaloha.zip”, kde “???” Je neco na porovnani :).
    Je neco takoveho? Teda verim ze je...
    E2E4
    E2E4 --- ---
    KOC256: no, teoereticky to muze postihovat jen bash.

    mkdir p; touch p/hz p/ch; echo *

    fakt vypise p/ch p/hz nebo naopak?

    kazdopadne porovnat poradi ve kterym to delal split oproti poradi ve kterym ti to dela shell muzes takhle:

    diff -u <(ls -tr) <(ls *)
    KOC256
    KOC256 --- ---
    E2E4: To me napadlo jako prvni. Mam eng. Ls sortuje ok
    E2E4
    E2E4 --- ---
    KOC256: mas cesky locale? (=pise ti to chybovy hlasky cesky?)

    v tom pripade mas problem s poradim pismena ch v abecede - split ho udela anglicky (cg ch ci), ale bash (ktery expanduje tu hvezdicku na seznam souboru) cesky (hz ch ia)

    pro anglicky poradi pouzij
    LC_ALL=C cat zaloha_part_* | md5sum

    pripadne si rovnou pridej do /etc/profile
    export LC_ALL=C
    MCKIDNEY
    MCKIDNEY --- ---
    Jinak nevim zda je to universalni ale sort by tam mel byt podle locale. V CentOSu je.
    Ten split jsem prave myslel rovnou do STDOUT, ale to bohuzel split podle byte size neumi.
    MCKIDNEY
    MCKIDNEY --- ---
    Snazit se to promazavat jak se to rozbaluje je vyssi divci - slo by to ruznymi zpusoby a zadny si nedokazu predstavit jako vhodny.

    Nicmene na tohle se pouziva prave Chunks/Lines pro split. Tam totiz muzes poslat pouze Xty chunk z N chunku do STDIN a spocist samostatne. Koukal jsem ze pro size ta moznost neni.
    KOC256
    KOC256 --- ---
    MCKIDNEY:
    Znovu uz to splitnout nemohu. Lepereceno leda on the fly. A sort muzu zkusit. Ale spise by byl problem leda kdyby to joinoval podle data zmeny. Coz asi nema duvod.

    Pripadne jde delat ten cat/join tak ze dany soubor co pripoji rovnou smaze/prepise aby mi zmizely ty party a zustal ten velky?
    MCKIDNEY
    MCKIDNEY --- ---
    [martin@hrudickova ~]$ echo 12 > test
    [martin@hrudickova ~]$ cat test | md5sum
    2737b49252e2a4c0fe4c342e92b13285  -
    [martin@hrudickova ~]$ split -b 1 test test_
    [martin@hrudickova ~]$ cat test_* | md5sum
    2737b49252e2a4c0fe4c342e92b13285  -
    [martin@hrudickova ~]$ cat $(ls test_* | sort) | md5sum
    2737b49252e2a4c0fe4c342e92b13285  -
    
    MCKIDNEY
    MCKIDNEY --- ---
    KOC256: Mozna bych overil spis obracene tim ze to znova splitnu a spoctu oddelene md5sum a porovnam.

    Nicmene si nemyslim ze je to vec poradi (muzes seradit pomoci sort, ale melo by to byt spravne protoze to split zapisuje postupne)



    SAMGARR
    SAMGARR --- ---
    KOC256: cat zaloha_part a potom Esc, Esc, je to ve spravnem poradi?
    KOC256
    KOC256 --- ---
    Ahoj
    Mám soubor s velkou zalohouv radech stovek GB. Abych s tim rozumeji mohl manipulovat, tak jsem si to SPLITem rozdelil na zaloha_part_aa, ab, ac, ...

    split -b 10G zaloha.zip zaloha_part_ --verbose

    Chci overit konzistenci, ale uz nemam misto pro treti kopii te zalohy (puvodni, rozdelene, nove spojene), tak jsem to chtel udelat jako:
    cat zaloha_part_* | md5sum > md5.txt

    v souboru nasledne najdu, ale jiny hash, nez je ten co mam z puvodni zalohy:
    md5sum zaloha.zip

    Je chyba v tom si myslet, ze ten CAT to posklada spravne porade? Nebo lze nejak podstrcit seznam souboru treba pomoci "ls", ktery je vraci ve spravnem poradi...

    Asi bych se chtel vyhnout JOINu a urcovani poradi vsech desitek souboru :(
    DANIELSOFT
    DANIELSOFT --- ---
    TEAPACK: (to je celkem sranda když se někdo v nějakém windowsovém/obecném sw klubu zeptá na software, tak když někdo dá CLI napíše asi "jestli nevadí, že je to jen z řádky" v linuxovém klubu zase naopak "jestli nevadí GUI" :) )
    TEAPACK
    TEAPACK --- ---
    MA747: jestli nevadí GUI, tak klidně pdfshuffler ;) ten to pofackuje korektně
    RAINBOF
    RAINBOF --- ---
    pdfsam uz neni pro linux ?
    E2E4
    E2E4 --- ---
    MA747: ghm Tak to me nepřekvapuje, to to prostě dá za sebe.. použij nějaký pdf2pdf nebo pdfmerge..
    MA747
    MA747 --- ---
    E2E4: Spojoval jsem to následovně: gs -q -sPAPERSIZE=letter -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=output.pdf *.pdf.
    Zkusím pohledat, díky.
    E2E4
    E2E4 --- ---
    MA747: asi ta PDF chce spojit nějak lépe, zjevně to před každou stránkou láduje do tiskárny fonty a kdoví co..

    možná jinej driver pro ghostscript
    MA747
    MA747 --- ---
    E2E4: Kupodivu ten gs merge netrval dlouho, asi 15 sek. Ani zahájení tisku toho spojeného pdf. Problém je, že mezi tiskem jedn. stránek byla cca 3 sek prodleva, což by podle mě být nemělo. Jen idle time na 100 stránek dělá 5 minut. Tiskárna by měla zvládnout 30+ stránek za minutu, tzn. za 3,3 min. by mělo být hotovo - jak jsem psal, pod win se ta stejná tiskárna nezastaví. Rád bych zachoval pořadí souborů. Zkusím příště Okular a nebo rovnou gs. Nicméně díky za odpověď.
    E2E4
    E2E4 --- ---
    MA747: musíš to paralelizovat:

    lp a* &
    lp b*

    ale nevyleze to ve správném pořadí..

    spojit do jednoho pdf a tisknout přes LP/gs zas bude hodně dlouho čekat než to gs zchrousta celé..

    takže nejlepší asi

    lp prvních 10 spojených &
    lp zbytek 11-99 spojených.

    první lp se dostane k lizu dřív než ten zbytek a čekání než gs zpracuje zbytek využijes tiskem těch prvních 10.

    MA747
    MA747 --- ---
    Poradil by mi pls někdo jak vytisknou najednou cca 100 PDF souborů bez čekání mezi jednotlivými soubory? Zkoušel jsem lp *.pdf, ale prodleva je asi 15+ sek. Co jsem hledal a pochopil, tak se tiskne přes ghostscript a proto to tak trvá. Teď jsem to "vyřešil" spojením do jednoho pdf (přes gs) a tisknu z Foxitreaderu, ale stále je tam asi 3 sek prodleva. Co si pamatuji z Windows, tak tam probíhal tisk mnohem rychleji. A bohužel Foxit pod linuxem nemá funkci bulk print.

    A ještě jedna věc. Když si zobrazím tisk.frontu přes lpq, jde zajistit, aby ukázal skutečnou velikost souboru k tisku? Jde o to, že jsem měl ve frontě cca 80 souborů s dlouhým jménem a diakritikou, ktere lpq nezobrazí celé. Snažil jsem se k nevytištěným dostat přes velikost, ale smůla. lpq připočítává (dorovnává) např. 996 bajtů.
    Kliknutím sem můžete změnit nastavení reklam