Command Line

Bár a gpg kapcsán legtöbbször a nyilvános kulcsú rejtjelezést említik, használhatjuk "hagyományos" ( szimmetrikus kulcsú ) rejtjelezésre is.

Tételezzük fel, hogy teszt.txt fájlunkat szeretnénk titkosítani:

gpg -c --cipher-algo AES256 teszt.txt

A parancs kétszer rákérdez a jelszóra, az eredmény a titkosított teszt.txt.gpg fájl. A titkosításnál meg lehet adni, milyen algoritmust szeretnénk használni, a példában 256-bites AES-t választottam. Hasznos kapcsoló lehet még a -z 0, ami kikapcsolja a tömörítést, erre leginkább akkor van szükségünk, ha tömörített fájlt szeretnénk titkosítani.

Az eredeti fájl tartalmát a következő paranccsal kaphatjuk vissza:

gpg -o teszt2.txt -d teszt.txt.gpg

Alapesetben a standard outputra írja ki gpg az eredményt, a -o kapcsolóval adhatjuk meg az output fájl nevét. Nem túl meglepő módon a parancs rákérdez a jelszóra is.

Egy elég bosszantó hibába futottam bele nemrég. Egy nagy file tömörítése után gunzip -l paranccsal megnéztem mennyire sikerült a tömörítés, és a következő furcsa eredményt kaptam:

$ gunzip -l nagy.gz
         compressed        uncompressed  ratio uncompressed_name
         4403498359           207437312 -2022.8% nagy

Vagyis gunzip szerint egy 200MB-s fájlt tömörítettem össze 4.4GB-ra, ami nyilván nem igaz. Némi utánaolvasás ( értsd: jó sok időt elszúrtam vele ) után a következő részt találtam gzip man oldalán:

The  gzip  format  represents  the  input size modulo 2^32, so the --list option reports incorrect uncompressed sizes and compression ratios for uncompressed files 4 GB and larger.  To work around this problem, you can use the following command to discover a large uncompressed file's true size:

             zcat file.gz | wc -c

Ami szabad fordításban annyit tesz, hogy 4GB-nál nagyobb tömörítetlen fájloknál hülyeséget ír ki gunzip, és nem is valószínű, hogy hamarosan megjavítják.

A javasolt megoldás valóban működik, bár érthető módon igen lassú:

$ zcat nagy.gz | wc -c
4502404608
 A megoldásból az is látszik, hogy csak a méret kiírásával van gondja gzip-nek, valójában képes a nagy fájlokat kicsomagolni.

Nagy Attila alkalmazáshalmazára szeretném felhívni a figyelmet. A standard linuxos eszközök mintájára készített egy csomagot:

• A parancsok teljesen egyformán működnek Linux és Windows alatt.
• A csomag Linux és Windows alatt is natív.
• A parancsok kompatibilitásak a standard eszközökkel.
• Reguláris kifejezések helyett saját paraméterezési lehetőségek.

A csomag letölthető a weboldalról, ahol elég sok példát is találhatunk.

A pdftk programcsomag segítségével parancssorból módosíthatjuk a pdf fájlokat.

Kivághatunk bizonyos oldalakat egy pdf-ből:

pdftk input.pdf cat 2-3 8-10 output out.pdf

Összeragaszthatunk pdf fájlokat (erről a feladatról korábban már írtam):

pdftk input1.pdf input2.pdf cat output output.pdf

A két lépést akár ötvözhetjük is:

pdftk A=input1.pdf B=input2.pdf cat A1 B3-4 output output.pdf

A Linux operációs rendszer alatt leggyakrabban használt shell program a bash, az összetett program tudásának azonban többnyire csak töredékét használjuk.

Valószínűleg mindannyian használjuk a parancsok és filenevek kiegészítésének lehetőségét. Elég a parancs első betűit beírnunk és a TAB billentyűt leütnünk, és a shell megpróbálja kiegészíteni a parancsot. Ha csak egy parancs kezdődik a beírt betűkkel, akkor automatikusan kiegészítődik, ha több lehetséges kiegészítés is van, akkor a TAB újbóli lenyomása után megkapjuk a lehetséges parancsok listáját.

Ha a parancsot már beírtuk, akkor a TAB a filenevek kiegészítését segíti. Mivel parancssorban gyakran adunk filenevet paraméternek, ez a kiegészítési mód nagyon hasznos.

Vannak esetek, amikor nem szerencsés, hogy az összes file nevét figyelembe veszi a shell a kiegészítéskor. Ha az acroread vagy xpdf parancsokkal egy pdf dokumentumot szeretnénk megnézni, akkor sokkal jobb lenne, ha a kiegészítés csak a pdf kiterjesztéssel rendelkező file-okat venné figyelembe.

Szerencsére elég régóta (bash 2.04 béta verziójától kezdve) lehetőségünk van a kiegészítés átprogramozására a beépített complete utasítás segítségével.

complete -f -X '!*.pdf' acroread

Az utasítás hatására az acroread parancs után csak a pdf kiterjesztéssel rendelkező file-okat veszi figyelembe a shell. A -f opció jelöli, hogy a kiegészítésben a fileneveket kell figyelembe venni, a -X opció után azt kell megadnunk (egy mintával), melyeket nem akarunk a kiegészítés során használni. Ezért kellett a példában a negálást jelző felkiáltójelet használnunk, hiszen mi csak a *.pdf mintára illeszkedő fileneveket szeretnénk használni. Ha több kiterjesztést is szeretnénk engedélyezni, vagy több programhoz is ugyanazokat a kiterjesztéseket használni, akkor ezt is könnyen megtehetjük:

complete -f -X '!*.@(dvi|DVI)' dvips dviselect dvitype

Az utasítás hatására a dvips, dviselect és dvitype parancsok után csak a .dvi vagy .DVI kiterjesztéssel rendelkező file-okat veszi figyelembe a bash. A példában a kiegészítés során a filenevek listájából választhattunk. Vannak olyan esetek is, amikor nem file-okra van szükségünk, hanem például a felhasználók nevére. Ilyenkor a -f helyett más opciót kell használnunk. A következő táblázat a legfontosabb opciókat tartalmazza, a teljes listát a man bash segítségével ismerhetjük meg.

Ha a finger, su, usermod, userdel, passwd parancsok után csak a felhasználók nevét szeretnénk használni, könnyen megtehetjük a következő paranccsal:

complete -u finger su usermod userdel passwd

Bár a fentiek alapján mindenki saját maga tudja programozni az automatikus kiegészítést, egyszerűbb letölteni egy olyan programot, ami megteszi ezt helyettünk. A bash-completion csomag több mint száz parancs (pl. man, cvs, rpm, find, apt-get, ...) automatikus kiegészítését programozza át. A fenti egyszerű példákat mind a csomagból vettem, a csomag természetesen sokkal bonyolultabb példákat is tartalmaz, olyanokat például, ahol a parancs korábbi paraméterétől is függ a kiegészítés.

Ha szeretnénk megnézni, miként működik a csomag, vagy szeretnénk esetleg kiegészíteni, akkor a /etc/bash_completion file-t illetve a /etc/bash_completion.d alkönyvtárat kell megnéznünk.

Parancssorból gyárthatunk QR-kódokat qrencode segítségével:

qrencode -o cli.png "http://commandline.blog.hu"


Az eredményül kapott cli.png fájl:

Egy QR-kód olvasóval beolvasva a fenti képet, a blog főoldalára jutunk.

Process-ek közti keresésnél hasznos a pgrep ( procps csomag része ) parancs:

$ pgrep gzip
23891
$ pgrep -l gzip
23891 gzip
$ pgrep -lf gzip
23891 gzip hdd_20070910.dmp

Látható, hogy alapértelmezés szerint csak a process azonosítóját írja ki, de -l kapcsoló hatására kiírja a nevet, -lf hatására pedig a parancs argumentumait is.

Természetesen a pontos parancsnév helyett használhatunk reguláris kifejezéseket is:

$ pgrep -l h.*d$
2 kthreadd
19 khungtaskd
40 khubd
1165 hald
2256 sshd
2285 httpd
2318 httpd
2324 httpd
2325 httpd
4696 sshd

A korábbi bejegyzésekkel ellentétben itt nem egy parancsot mutatok be, hanem egy valódi probléma megoldását. Egy elég öreg Windows XP-s laptopban cseréltem ki a HDD-t (merevlemezt) SSD-re. A feladat során a következő céljaim voltak:

• Windows XP újrainstall nélkül megoldani az egészet,
• miközben a HDD-nél kisebb SSD-t szerelek be,
• az egyészet linuxos parancssorral oldom meg (különben hogyan írnék róla ide?),
• az egész folyamat során nem írok a HDD-re (vagyis baj esetén sem történhet nagy baj).  

Eszközök

Egy pendrive-ról bootoltam Linuxot, így nem volt szükség külön linuxos gépre. A következő eszközökre fogok hivatkozni a leírásban:

• /dev/sda:  Az eredeti 80GB-os HDD.
• /dev/sdb: A pendrive (ezt nem fogom használni).
• /dev/sdc: Egy kellően nagy háttértár.
• /dev/sdd: Az új 64GB-os SSD.

Ha valaki a leírást szeretné követni, akkor persze ellenőrizze, hogy nála milyen névvel kell hivatkozni az eszközökre. 

HDD tartalmának lementése

Első lépésként a régi merevlemez teljes tartalmát elmentettem egy nagy fájlba:

mkdir /mnt/diskc
mount /dev/sdc1 /mnt/diskc
dd if=/dev/sda of=/mnt/diskc/sda.img


NTFS partíció átméretezése

Az így elmentett sda.img fájl partícióit ellenőriztem fdisk segítségével:

$ fdisk -l /mnt/diskc/sda.img
Disk /mnt/diskc/sda.img: 80.0 GB, 80026361856 bytes
240 heads, 63 sectors/track, 10337 cylinders, total 156301488 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x94e494c4

             Device Boot      Start         End      Blocks   Id  System
/mnt/diskc/sda.img1   *          63   138907439    69453688+   7  HPFS/NTFS/exFAT
/mnt/diskc/sda.img2       138907440   156295439     8694000    c  W95 FAT32 (LBA)


A 2. partíció a Windows XP install anyagát tartalmazza, ezt nem fogom átmásolni az SSD-re, a továbbiakban csak az 1. partícióval foglalkozok. Az első partíciót losetup segítségével érhetjük el:

losetup -o $((63*512)) /dev/loop1 /mnt/diskc/sda.img
mkdir /mnt/diska1
mount /dev/loop1 /mnt/diska1
umount /mnt/diska1


A partíció átméretezéséhez az ntfsresize programot használtam:

$ ntfsresize --info /dev/loop1
ntfsresize v2011.4.12AR.7 (libntfs-3g)
Device name        : /dev/loop1
NTFS volume version: 3.1
Cluster size       : 4096 bytes
Current volume size: 71120577024 bytes (71121 MB)
Current device size: 80026329600 bytes (80027 MB)
Checking filesystem consistency ...
Accounting clusters ...
Space in use       : 59315 MB (83.4%)
Collecting resizing constraints ...
You might resize at 59314573312 bytes or 59315 MB (freeing 11806 MB).
Please make a test run using both the -n and -s options before real resizing!
$ ntfsresize -n -s 63500 /dev/loop1
$ ntfsresize -s 63500 /dev/loop1

Az első parancs alapvető információkat ír ki a partícióról, a legfontosabb az, hogy mi az a legkisebb méret amire át lehet méretezni (59315 MB). A második paranccsal szimulálom a 63.5GB-re méretezést. Ennek eredményeként azt írta a program, hogy minden menni fog. Az utolsó parancs végzi a tényleges munkát.

Érdemes megjegyezni, hogy egyáltalán nem biztos, hogy minden átméretezés sikerül ami --info alapján lehetségesnek tűnik. Teszt során nekem úgy tűnt, érdemes minél több helyet felszabadítani. Mások töredezettségmentesítésre esküsznek. Kétszer egymás után.

MBR átmásolása

 A HDD-ről át kell másolni az MBR-t az új SSD-re. Bár elvileg az első szektor tartalmazza az MBR-t, és a leírás alapján elegendő lenne az első 440 (vagy 446) byte átmásolása (hiszen utána a partíciós tábla található), egy NTFS boot rekordot bemutató leírás (amiből többet meg lehet tudni az NTFS bootról mint amennyit valaha szerettem volna megtudni) alapján az ezt követő szektorok is tartalmaznak hasznos információt. Az egyszerűség kedvéért átmásoltam mindent ami az első partíció előtt található a merevlemezen:

dd if=/mnt/diskc/sda.img of=/dev/sdd bs=512 count=62

Utólag írva a leírást már látom, hogy a fenti logika alapján valójában 63 szektort kellett volna átmásolni 62 helyett, de a gyakorlatban ez nem fontos.

Partíciós tábla módosítása

Az előző másolás során az eredeti partíciós tábla adatai is átmásolódtak, ami nyilván teljesen rossz. Először is fdisk segítségével töröltem a 2 eredeti partíciót, majd fdisk-et újraindítottam. Ezután létrehoztam egy új partíciót ami elfoglalja a teljes 64GB-ot. Típusa ugyanolyan ( 7 - HPFS/NTFS/exFAT ) mint az eredeti 1. partíció. Ezt a partíciót bootolhatóvá tettem. Az új partíciós tábla:

Disk /dev/sdd: 64.0 GB, 64023257088 bytes
22 heads, 16 sectors/track, 355242 cylinders, total 125045424 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x94e494c4

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048   125045423    62521688    7  HPFS/NTFS/exFAT

Látszik az is, hogy itt már nem a 63. szektoron kezdődik a partíció, hanem a 2048. szektoron. Itt olvashatunk bővebben arról, hogy ez miért is jó. 

Partíció tartalmának átmásolása

A már korábban említett losetup segítségével létrehoztam egy eszközt ami a SSD 1. partíciójára mutat, és átmásoltam az átméretezett partíció tartalmát (63.5GB-ot).

losetup -o $((2048*512)) /dev/loop2 /dev/sdd
dd if=/dev/loop1 of=/dev/loop2 bs=512 count=$((63500000000/512))


NTFS boot rekord módosítása

Ahogy a már említett NTFS Boot leírás említi, illetve ahogy némileg érthetőbben itt is le van írva, mivel az SSD-n az 1. partíció nem ugyanazon a pozíción kezdődik mint ahogy a HDD-n kezdődőtt, ezért módosítanunk kell a partíció első szektorában a "Hidden Sector Count" értékét. A következő dump mutatja az 1. partíció tartalmának első 32 byte-ját:

0000000 eb 52 90 4e 54 46 53 20 20 20 20 00 02 08 00 00
0000020 00 00 00 00 00 f8 00 00 3f 00 f0 00 3f 00 00 00


A kijelölt rész a következő 3 számot tartalmazza (little endian byte-sorrendben):  63, 240, 63. Az első két számot nem módosítottam, de a 3. számot 2048-ra írtam át xxd segítségével:

echo 00: 3F 00 F0 00 00 08 | xxd -r > /mnt/diskc/ntfs_change.dat
dd if=/mnt/diskc/ntfs_change.dat of=/dev/sdd1 bs=1 count=6 seek=24

Felmerülhet e kérdés, minek írok 6 byte-ot, ha csak 2-t változtatok meg. Nos, a fenti dokumentációk alapján úgy tűnt, hogy a szektor/track és fejek száma mezőket is módosítani kell az fdisk által jelzett új értékekre. Így nem volt hajlandó bootolni az SSD, így végülis visszaírtam az eredeti értékeket.

Nem igazán világos, hogy mi értelme van egy partíció első szektorára felírni azt, hogy hol is kezdődik a partíció. Ezt az adatot csak akkor tudjuk beolvasni, ha már amúgy is tudjuk a partíció helyét.

Végső lépések

Ennél a pontnál kikapcsoltam a gépet és átszereltem a régi HDD helyére az SSD-t, majd bebootoltam Windows XP-t. Elsőre persze panaszkodott, hogy valami babrálta a merevlemezt ( ntfsresize állítja be a flaget ) ezért ellenőrzést futtatott. Ezután bootolt, majd jelezte hogy új hardvert talált. Ezután megint bootolt, és minden működött rendben.

Egy korábbi bejegyzésben írtam arról, miként lehet egy image fájl adott részét felmountolni:

mount -o loop,offset=$((138907440*512)) hdd_image.img /mnt/test

A módszer egyik elég komoly hátránya ( a "rendes" device-ok használatával szemben), hogy feltételezi, hogy mount kezeli a loop device-okat, és az offsetet. Nem mindig van ilyen szerencsénk, előfordulhat, hogy olyan programot kell használnunk, ami nem támogatja ezt. Ilyenkor losetup segítségével hozhatunk létre olyan eszközt, amit már kényelmesebb használni. A fenti példa losetup használatával, amikor mount-nál már nincsen szükség semmi speciális kapcsolóra:

losetup -o $((138907440*512)) /dev/loop1 hdd_image.img
mount /dev/loop1 /mnt/test


Elsőre úgy tűnik, az xxd az od-hez hasonló program, aminek segítségével egy fájl tartalmát dumpolhatjuk ki:

$ echo alma | xxd
0000000: 616c 6d61 0a                             alma.

Ezen kívül van viszont egy nagyon hasznos szolgáltatása xxd-nek, képes a fordított irányban is dolgozni, vagyis nagyon könnyen tudjuk a segítségével egy fájl tartalmát hexadecimális kódokkal feltölteni:

$ echo 00: 42 61 72 61 63 6b | xxd -r > test.txt
$ cat test.txt
Barack


A DVD-hez hasonló módon egy teljes merevlemezről is készíthetünk biztonsági mentést:

dd if=/dev/sda of=hdd_image.img

Ebben az esetben az adatok elérése kissé bonyolultabb, hiszen a mount parancs segítségével nem teljes merevlemezt, hanem partíciót érünk el, így ki kell számolnunk, hol is kezdődnek a partíciók. Az fdisk parancs segítségével kaphatunk információt:

# fdisk -lu hdd_image.img

Disk hdd_image.img: 80.0 GB, 80026361856 bytes
240 heads, 63 sectors/track, 10337 cylinders, total 156301488 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x92e474f4

        Device Boot      Start         End      Blocks   Id  System
hdd_image.img1   *          63   138907439    69453688+   7  HPFS/NTFS/exFAT
hdd_image.img2       138907440   156295439     8694000    c  W95 FAT32 (LBA)


 Mivel fdisk a fenti esetben 512 byte-os egységekben számol, ezért a 2. partíció a 138907440*512. byte-on kezdődik. Vagyis a következő paranccsal érhetjük el a 2. partíciót:

 mount -o loop,offset=$((138907440*512)) hdd_image.img /mnt/test


Az fdisk-et is tartalmazó util-linux-ng csomag 2.17-es verziójában nem működött rendesen a fenti módszer, 2.19-re kellett frissítenem.

Hiába a sok parancssoros program, ha egy olyan gépen kell rendet tennünk ahol nem indul el az operációs rendszer, vagy elindul, de nincs rajta a kedvenc programjaink gyűjteménye.

Tulajdonképpen bármilyen kicsi (pendrive-on elférő) Linux megfelel a célnak, hiszen pendrive-ról bootolva elérhetjük a merevlemezt és rendet tehetünk. Az általam éppen most használt gparted live-ot partíciókezelő programok ( parted, gparted ) köré építették, így ideális, ha merevlemezzel kapcsolatos teendőink vannak.

Ha nagyon hosszú ideig futó scripteket írunk, akkor nem túlzottan jó, ha a futás ideje alatt a gépünk nagyon belassul. Legegyszerűbb (és persze nem teljesen tökéletes) megoldás, ha alacsonyabb prioritással indítjuk el a scriptet:

nice -n 19 script.sh

Ha indítás után jövünk rá, hogy a prioritáson változtatni szeretnénk, akkor a renice parancs segíthet.

renice -n 19 11111

ahol 11111 a process azonosítója.

Bár Linux alatt nem feltétlenül szeretnénk használni, időnként találkozhatunk Microsoft Cabinet fájlformátummal. Én leginkább windowsos drivereknél botlok bele. Ha ki szeretnénk csomagolni, akkor a cabextract segítségével tehetjük meg. Ez nemcsak a .cab kiterjesztés esetén, hanem önkicsomagoló .exe esetében is működik.

Ha gyakran használunk parancssort, akkor a két legismertebb editor (vi, emacs) közül legalább az egyiket illik ismernünk. ( Abba a vitába most nem mennék bele, hogy melyik a jobb ).

Mindkét editorra igaz, hogy eleinte nagyon kényelmetlen a használatuk, kell egy kis idő míg megtanulja az ember az alapokat. Ebben a tanulásban segít egy interaktív vi ( pontosabban vim ) tutorial.

forrás: lifehacker.com

Ha spórolni szeretnénk pdf nyomtatás során a papírral, éredemes egy oldalra több oldalnyi információt is összezsúfolni pdfnup (pdfjam csomag része) segítségével:

pdfnup UnixTextProcessing.pdf --nup 2x1


pdfnup UnixTextProcessing.pdf --nup 2x2


pdfnup UnixTextProcessing.pdf --nup 4x2

A --nup kapcsoló után az oldalak elrendezését kell megadni. A fenti 3 példa rendre 2, 4, 8 eredeti oldalból készít 1 új oldalt. Az eredmény ehhez hasonló (képekre kattintva nagyobb méretben is meg lehet nézni):

Ha rendet szeretnénk tartani a merevlemezünkön, akkor az egyik legfontosabb dolog, hogy feleslegesen ne tároljuk ugyanazt a fájlt többször. Ha át szeretnénk nézni a merevlemezt, hogy van-e rajta duplán tárolt fájl, akkor fdupes segíthet.

$ fdupes -rn photos
photos/alma/readme.txt
photos/aaa/readme.txt
photos/alma/readme.txt~

photos/sheaffer_snorkel/imgp1764.jpg
photos/sheaffer_snorkel/sac_protector.jpg

photos/process/kozgyuru/dof_kozgyuru.tif
photos/process/kozgyuru/dof_kozgyuru_4.tif
photos/process/kozgyuru/dof_kozgyuru_5.tif

A parancs photos alkönyvtárat és az alkönyvtárait (-r kapcsoló ) vizsgálja meg azonos fájlok után kutatva. Az eredményeket csoportosítva írja ki. Látható, hogy észreveszi azt is, amikor a fájl neve eltér, és azt is, amikor a fájlok nem ugyanabban az alkönyvtárban vannak. A -n kapcsoló hatására a teljesen üres fájlokat ignorálja.

Ha a diff segítségével két fájlt szeretnénk összehasonlítani, akkor könnyű dolgunk van, de ha két parancs eredményét kell összehasonlítani akkor már nehezebb a helyzet. Én azt vettem észre, ilyenkor a többség két ideiglenes fájl készít, és azokat hasonlítja össze. Tegyünk fel, két fényképet készítettünk, és össze szeretnénk vetni exiftool segítségével a felvételek paramétereit:

exiftool virag-0000.dng > v0.txt
exiftool virag-0001.dng > v1.txt
diff v0.txt v1.txt

Ehelyett sokkal egyszerűbb process helyettesítést alkalmazni:

diff <(exiftool virag-0000.dng) <(exiftool virag-0001.dng)

Az eredmény mindkét esetben valami ehhez hasonló:

73c73
< Preview Image Length            : 13585
---
> Preview Image Length            : 13407
77c77
< Time                            : 09:09:56
---
> Time                            : 09:12:27
101c101
< Camera Temperature              : 26 C
---
> Camera Temperature              : 29 C
 

Két fájl tartalmát hasonlíthatjuk össze a diff parancs segítségével. Vegyünk két igen egyszerű szövegfájlt (a.txt illetve b.txt):

Ez egy
kicsit
meg fog válllltozni.
Persze a sorok
nagy
része
változatlan
marad.

Ez egy
kicsit
meg fog változni.
Persze a sorok
nagy
része
változatlan
marad.

Ezután a két fájlt összehasonlítva:

$ diff a.txt b.txt
3c3
< meg fog válllltozni.
---
> meg fog változni.

 Látható, hogy csak a megváltozott részeket mutatja a parancs.

Lehetőségünk van arra is, hogy egymás mellett lássuk a két fájlt, a különbségeket kiemelve:

$ diff -y a.txt b.txt
Ez egy                                Ez egy
kicsit                                kicsit
meg fog válllltozni.             |    meg fog változni.
Persze a sorok                        Persze a sorok
nagy                                  nagy
része                                 része
változatlan                           változatlan
marad.                                marad.

Végül az utolsó példa akkor lehet hasznos, ha csak arra vagyunk kíváncsiak, van-e különbség a 2 fájl között:

$ diff -q a.txt b.txt
Files a.txt and b.txt differ

 

Ha parancssort használunk, elég gyakran előfordul, hogy az előző parancsot szeretnénk újrafuttatni apróbb változtatásokkal.

Ha csak egy változtatásra van szükségünk, akkor a ^ segítségével végezhetjük el a cserét:

$ echo "ez egy teszt"
ez egy teszt
$ ^egy^ketto
echo "ez ketto teszt"
ez ketto teszt

A fenti módszer az "egy" első előfordulását cseréli csak át. Ha az összeset szeretnénk, akkor kicsit bonyolultabb parancsra van szükségünk:

$ echo "ez egy uj teszt. egy alma"
ez egy uj teszt. egy alma
$ !!:gs/egy/ketto
echo "ez ketto uj teszt. ketto alma"
ez ketto uj teszt. ketto alma

Mondanom sem kell, óvatosan érdemes bánni a lehetőséggel, igen könnyen adhatunk ki hibás parancsot.

Arról már írtam, miként tudunk sok jpg fájlból egy pdf fájlt készíteni, most az ellentétes irányt mutatom meg, amikor egy pdf oldalait mentjük el jpeg fájlokba:

convert input.pdf output_%02d.jpg

Az eredményt oldalanként 1 jpeg fájl: output_00.jpg, output_01.jpg, output_02.jpg...

Alapesetben 72dpi-nek megfelelő fájlok készülnek, de ezt módosíthatjuk, ha jobb minőségre van szükségünk:

convert -density 300 input.pdf output_%02d.jpg

A fenti esetben az összes oldalt konvertálja a parancs, ha erre nincsen szükségünk, megadhatjuk a konvertálandó oldalak sorszámát. Ha az 5. 6. 7. oldalt szeretnénk csak feldolgozni:

convert -density 300 input.pdf[5-7] output_%02d.jpg

Érdemes még megjegyezni, hogy egy bug miatt imagemagick 6.6-ban néha csak az első oldalt konvertálta a parancs, az újabb verzióban már javították a bugot.

Bár az elektronikus könyveket kezelő calibre alapvetően grafikus program, több funkciója parancssorból is használható. Az elektronikus könyvek metaadatait az ebook-meta programmal olvashatjuk ki, vagy módosíthatjuk.

Alapesetben kiírja a könyv metaadatait:

$ ebook-meta Doyle_Sherlock_Holmes_kalandjai.prc
Title               : Sherlock Holmes kalandjai
Author(s)           : Sir Arthur Conan Doyle
Publisher           : Kindlevarázs
Tags                : Classics
Language            : hu
A borító kiolvasásához a --get-cover kapcsolót használhatjuk:

ebook-meta Doyle_Sherlock_Holmes_kalandjai.prc --get-cover sherlock.jpg

A metaadatokat persze módosíthatjuk is. A borítót például a következő módon cserélhetjük le:

ebook-meta Doyle_Sherlock_Holmes_kalandjai.prc --cover újborító.jpg

Bár vannak egyszerűbb módok is, ha pdf fájlokat kell összefűzni, legtöbbször a jó öreg ghostscriptet használom, ezzel van a legkevesebb probléma:

gs -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOUTPUTFILE=egyben.pdf elso.pdf masodik.pdf

Egy korábbi bejegyzésben írtam a du parancsról, aminek segítségével az alkönyvtárak által elfoglalt lemezterületet tudjuk ellenőrizni. Az ott leírt módszer nem használható, ha nem az egész alkönyvtárra vagyunk kíváncsiak, csak az ott található fájlok egy részére.

Egy alkönyvtáramban vegyesen vannak tömörített és tömörítetlen log fájlok. A tömörítetlen logfájlok összméretére voltam kíváncsi:

find . -name "*.log" -printf "%s\n"|awk '{sum+=$0}END{print sum}'

Némi magyarázat:

• A find paranccsal kerestem meg az engem érdeklő fájlokat. Itt elég egyszerű a szabály.
• A -printf "%s\n" hatására find nem a talált fájlok neveit írja ki, hanem a fájlméreteket szépen külön sorban.
• Az így kapott számokat awk segítségével adom össze.
• A legvégén (END) pedig kiiratom az összeget.

A szimbolikus linkek használata igen sokszor megkönnyíti az életünket. Tipikus példája a használatuknak amikor egy folyamatosan változó verziójú fájlnál egy link mutat a legutolsó verzióra:

 ls -l /lib/libz*
lrwxrwxrwx 1 root root    13 2010-10-29 15:56 /lib/libz.so.1 -> libz.so.1.2.3
-rwxr-xr-x 1 root root 74760 2010-01-06 15:05 /lib/libz.so.1.2.3


A programoknak elég annyit tudni, hogy a libz.so.1 fájlra van szükségük. Ha kijön az 1.2.4 verzió, akkor egyszerűen le lehet cserélni a linket, nem kell a programokat módosítani.

Eddig ha le kellett cserélnem egy szimbolikus linket, akkor 2 lépésben tettem meg. Tegyük fel alma.txt nevű linkünk alma-2.3.4.txt-re mutat, de alma-2.3.5.txt-re szeretnénk cserélni:

rm alma.txt
ln -s alma-2.3.5.txt alma.txt

A két parancsot persze && segítségével kötöttem össze.

Nemrég botlottam bele egy sokkal egyszerűbb megoldásba:

ln -sf alma-2.3.5.txt alma.txt

Ha pedig még kevesebbet szeretnénk gépelni:

ln -sf alma{-2.3.5,}.txt

Azt azért érdemes megjegyezni, hogy valójában ez sem atomi művelet, vagyis ha egy nagyon fontos fájlra mutató linket cserélünk így le, akkor van egy rövid időszak ameddig a link sehová sem mutat.