A 90-es évek végén ebből a könyvből tanultam a UNIX alapokat. Miután már rég nem árulják a könyvet elérhető weben is. Kezdőknek valószínűleg sokkal jobb egy logikusabb felépítésű könyvvel kezdeni, össze-vissza csapongó blogok helyett.
Aki papíron szeretné olvasni, az persze megveheti aktikváriumban is a könyvet, nekem is van eladó példányom a zsibvásáron.
Valószínűleg mindenki ismerti Unixban a fájlok jogosultságkezelését (itt írnak erről lényegesen részletesebben):
$ ls -l
-rw-r--r-- 1 user live 0 Nov 14 07:31 a.txt
Három jogosultságot (r: read, w: write, x: execute) adhatunk három szinten (user, group, other).
Bár többnyire elegendő ez a három szint, időnként felmerül, hogy jobb lenne felhasználói szinten kezelni a jogosultságokat. Egy darabig ez megoldható újabb és újabb csoportok létrehozásával, de nem mindig.
A pontosabb kezeléshez file access control list (file ACL) beállítására (setfacl) illetve lekérdezésére (getfacl) van szükség.
$ setfacl -m u:user2:r a.txt
$ ls -l a.txt
-rw-r--r--+ 1 user live 0 Nov 14 07:31 a.txt
$ getfacl a.txt
# file: a.txt
# owner: user
# group: live
user::rw-
user:user2:r--
group::r--
mask::r--
other::r--
Először user2 felhasználónak adtam olvasási jogot a fájlhoz, ezután ls -l egyetlen + jellel jelzi, hogy valami speciális jog is be van állítva (hasonlóan setcaphoz, ezt is nehéz észrevenni). A jogokat getfacl listázza ki részletesen, kiemeltem azt a sort ami jelzi a frissen beállított jogot.
Ahhoz, hogy használhassuk ezt, szükségünk van arra, hogy a fájlrendszer támogassa ACL-eket, és arra is, hogy megfelelő módon legyen felmountolva a fájlrendszer. Az esetek többségében ezzel nem kell törődnünk, a leggyakrabban előforduló fájrendszerek támogatják ezt.
A GNU emacs editort kétféle üzemmódban használhatjuk, karakteres és grafikus felülete is van. Akár már az installáláskor is választhatunk közülük, de jellemzően indításkor automatikusan választ a két üzemmód közül. Néha sajnos akkor is az X-es felületet indítja el amikor nem kellene, a következő egyszerű módon lehet a klasszikus karakteres felületet indítani:
emacs -nw
Ha írunk egy bash scriptet elég gyakori, hogy paramétereket is átadhatunk a scriptünknek, melyekre $1 $2 ... néven hivatkozhatunk. Szintén elég gyakori, hogy a paraméterek egy része opcionális. A következő igen egyszerű példában három paramétert fogad el a scipt, melyek alapértelmezett értékei rendre 100, 200, 300:
#!/bin/bash
echo ${1-100} ${2-200} ${3-300}
A script tesztelése:
$ teszt.sh a b c
a b c
$ teszt.sh a b
a b 300
$ teszt.sh a
a 200 300
$ teszt.sh
100 200 300
Bár nem igazán szoktam a nyelvek szintaxisát kritizálni, azért azt meg kell jegyeznem, hogy nem kicsit félrevezető a ${1-100} forma. Ha az 5. paraméterünk alapértelmezett értéke 1, akkor ${5-1}-et kell írni, ami még véletlenül sem ${4}.
Vertikális videót készíteni rettentően értelmetlen ( vonatkozó szakirodalom: itt ) de sajnos mégis igen elterjedt. Az ilyen videókat (melyeket nem én készítek!) ffmpeggel szoktam visszaforgatni:
ffmpeg -i input.mp4 -vf "transpose=1" -vcodec libx264 -b:v 1000k output.mp4
A transpose=1 az óramutató járásával megegyező irányban forgat 90 fokot.
Android alkalmazásokat tölthetünk le Google Play Store-ból gplaycli programmal:
Keressünk rá a "ZTE FC"-re az alkalmazások között:
$ gplaycli.py -s "ZTE FC"
Title Creator Size Downloads Last Update AppID Version Rating
ZTE FC NaviPro Richpoi 1.7MB 100+ 29 avr. 2015 com.mynews1.ztefc 3 4.67
Битва Замков - Castle Clash IGG.COM 75.9MB 5 000 000+ 24 août 2015 com.igg.castleclash_ru 1200290 4.75
Star Rocket Andosoft 5.4MB 50 000+ 13 août 2013 com.andosoft.starocket 8 3.53
Critical Strike Portable Critical Force Entertainment 48.0MB 10 000 000+ 15 déc. 2014 com.StudioOnMars.CSPortable 3589 4.22
Avira Antivirus Security AVIRA 9.9MB 10 000 000+ 1 sept. 2015 com.avira.android 3734 4.39
Synthèse vocale Google Google Inc. 18.9MB 1 000 000 000+17 juil. 2015 com.google.android.tts 210305063 4.01
Viber Viber Media S.à r.l. 38.0MB 100 000 000+ 1 sept. 2015 com.viber.voip 104 4.32
My BOLT! (Official) PT INTERNUX 11.1MB 500 000+ 13 août 2015 com.boltsuper4g.ioda 18 3.88
Radardroid Lite Ventero Tel. 7.8MB 5 000 000+ 7 août 2015 com.ventel.android.radardroid.lite 332 4.20
Navy Battle 3D BitmapPiranha 12.2MB 1 000 000+ 31 août 2013 com.bp.navybattle 12112 3.51
A táblázat alapján letölthetjük a minket érdeklő alkalmazást:
$ gplaycli.py -d com.mynews1.ztefc
A letöltéshez szükségünk van persze egy google accountra és egy android_ID-ra, ezt a credential.conf fájlban állíthatjuk be. Az esetek többségében jó a program által használ alapértelmezett beállítás, de használhatjuk a saját accountunkat is.
Nagyon hasznosnak tartom a szimbolikus linkeket, de ha letöröljük a fájlt amire mutatnak, akkor semmilyen hibajelzést nem kapunk, vagyis ha nem figyelünk egy idő után elszaporodnak a hibás szimbolikus linkek. Legegyszerűbb a következő módon kereshetjük meg a hibás linkeket:
$ find . -type l -xtype l
Ha valakit részletesebben érdekel, itt lehet bővebben olvasni a lehetséges keresési módszerek előnyeiről, hátrányairól.
Valószínűleg a blog első bejegyzése lehetetett volna a man parancs leírása, de valamiért feltételeztem, hogy a blog összes olvasója jól ismeri a man-t.
A legutóbbi stat-ról szóló bejegyzés írásakor viszont újra beleszaladtam a man egyik számomra bosszantó jellemzőjébe. A man oldalak típus szerint csoportosítva vannak, és sajnos előfordul, hogy bizonyos eseteben nem a minket érdeklő típust mutatja meg a man.
Például a stat 3 csoportban is megtalálható a gépemen (apropos segítségével a legkönnyebb ezeket megtalálni):
$ apropos stat | grep '^stat '
stat (3p) - get file status
stat (1) - display file or file system status
stat (2) - get file status
A különböző dokumentációkhoz a
$ man 1 stat
$ man 2 stat
$ man 3p stat
parancsokkal férhetünk hozzá.
A stat parancs alapesetben elég részletes információt ad egy fájlról:
$ stat cvsrm.sh
File: `cvsrm.sh'
Size: 19 Blocks: 8 IO Block: 4096 regular file
Device: 816h/2070d Inode: 1310786 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 501/ user) Gid: ( 501/ staff)
Access: 2010-11-05 09:04:19.000000000 +0100
Modify: 2005-09-01 09:15:44.000000000 +0200
Change: 2010-11-05 09:34:21.202519355 +0100
Ha scriptben szeretnénk használni, akkor a --format kapcsolóval tudjuk megadni, hogy pontosan mire is vagyunk kíváncsiak:
$ stat --format "%n %s %Y" cvsrm.sh
cvsrm.sh 19 1125558944
A példában a fájl nevet (%n), a fájl méretét (%s) és az utolsó módosítás idejét olvastam ki. Az elérhető mezőket a man-ban találjuk.
Az utolsó boot időpontját legegyszerűbben a következő módon tudhatjuk meg:
$ who -b
system boot 2015-08-18 18:46
Ha VHS-t próbálunk digitalizálni, akkor számomra nem teljesen érthető okokból az audio és a video sáv egymáshoz képest mindenképpen el lesz csúszva. A legjobb amit elértem, hogy az eltérés (nagyjából) konstans, vagyis egy kicsit elcsúsztatva rendben lesz a felvétel.
Ehhez hozzáadva, hogy a szalag elején és végén többnyire lesz egy felesleges rész, én a következő parancsot szoktam használni a digitalizált avi feldolgozásához:
mencoder -delay -3.2 -ss 00:56.5 -endpos 58:19 -oac copy -ovc copy -o output.avi input.avi
A -delay-nél adom meg az audio és video sáv közti különbséget másodpercben. Az -ss a kezdete, az -endpos a vége az engem érdeklő résznek. A fenti parancs nem kódolja újra a felvételt (-oac copy, -ovc copy) így nagyon gyorsan lefut.
Ha XML fájlokat kell összehasonlítanom, akkor a diff nem mindig túl hasznos, főleg ha nem én gyártottam az összehasonlítandó XML-eket. Egyrészt előfordul, hogy az XML gyártásnál nem használnak sortörést, másrészt pl. az attributumok sorrendje sem feltétlenül fix. Process helyettesítés és xmllint segítségével már jobban össze lehet hasonlítani az XML fájlokat:
$ diff <(xmllint --exc-c14n file1.xml | xmllint --format -) <(xmllint --exc-c14n file2.xml | xmllint --format -)
Nem gondoltam volna, hogy ezzel a hülyeséggel még találkozni fogok, de meglepve vettem észre, hogy az új laptopom nem játsza le a régiókódos DVD-ket, mert nincs kód beállítva a DVD drive-hoz. A regionset segítségével tudtam ezt beállítani.
Itt jönne az a rész, amikor mutatok példát a kód lekérdezésére, beállítására, de sajnos regionset kérdezz/felelek alapon működik, nem "igazi" parancssoros programként.
Külön bosszantó, hogy úgy tűnik a drive komolyan veszi, hogy legfeljebb 5-ször lehet módosítani a kódot. Aki teheti, ne Matshita DVD-t vegyen linuxos gépbe.
A less egyik hiányossága, hogy nem támogatja a syntax highlightot, de külső programmal rávehető erre. A source-hightlight installálása után a következő 2 környezeti változót kell beállítani
export LESS=' -R '
export LESSOPEN='| /usr/bin/src-hilite-lesspipe.sh %s'
és less már szépen színezi is a fájlokat.
Elég sokszor fordult elő velem, hogy belenéztem egy fájlba a less paranccsal, majd közben rájöttem, hogy editálni kellene a fájlt. Többnyire ilyenkor becsuktam less-t, majd elindítottam az editort.
Lehet ezt sokkal egyszerűbben is, a v billentyű lenyomására less elindítja az alapértelmezett editort (emacs, vi, ...) és rögtön editálhatjuk az éppen vizsgált fájlt.
Nemcsak a bzip2-nek van párhuzamos implementációja (pbzip2, lbzip2), hanem a jóval ismertebb gzipnek is. A pigz a tesztjeim szerint csak tömörítéskor párhuzamos, kitömörítéskor csak egy magot használ. Persze a kitömörítés többnyire elég gyors enélkül is.
Már korábban írtam a pbzip2-ről, ami egy párhuzamos bzip2 implementáció, és említettem, hogy az egyik hátránya az, hogy a hagyományos bzip2 programmal készült tömörített fájlok kitömörítésekor sajnos pbzip2 is csak egy magot használ.
Már abban a cikkben is említettem lbzip2-t, most elvégeztem néhány tesztet egy nyolcmagos gépen:
Gyártottam egy tömörített fájlt a hagyományos bzip2 programmal:
$ dd if=/dev/urandom of=/tmp/teszt1000MB bs=1024 count=1000K
1024000+0 records in
1024000+0 records out
1048576000 bytes (1.0 GB) copied, 91.707 s, 11.4 MB/s
$ time bzip2 -c teszt1000MB > teszt1000MB.bz
real 2m16.594s
user 2m15.187s
sys 0m0.802s
Ezután kitömörítettem bzip2, pbzip2, lbzip2 programokkal ugyanazt a fájl, és mértem a futási időt:
$ time bunzip2 -c teszt1000MB.bz > /dev/null
real 1m8.097s
user 1m7.887s
sys 0m0.264s
$ time pbunzip2 -c teszt1000MB.bz > /dev/null
real 1m9.206s
user 1m9.689s
sys 0m0.300s
$ time lbunzip2 -c teszt1000MB.bz > /dev/null
real 0m16.764s
user 2m9.889s
sys 0m1.724s
Látszik a számokból (real és user összehasonlításából), hogy bzip2 és pbzip2 egyetlen magot használ, miközben lbzip2 szépen használja az összes magot ilyen esetben is. Vagyis lbzip2 ilyen esetekben sokkal gyorsan pbzip2-nél.
Valószínűleg már mindenki olvasott a shellshock bugról amit bash-ban találtak. A bug kb. 20-25 éve van egyébként a bash-ban. Szinte mindenhol ugyanazt az egysoros példát említik amivel ellenőrízhetjük, hogy bugos-e a bash-unk (persze hogy az), de nem igazán magyarázzák el részletesen, hogy mi is a baj.
Környezeti változót valószínűleg már mindenki használt bash-ban:
$ echo $A
$ A=a
$ echo $A
a
Ha azt szeretnénk, hogy a környezeti változó értéke csak egyetlen parancs végrehajtásának idejére változzon meg, akkor egy sorban a következőt kell használnunk:
$ B=bb bash -c 'echo $B'
bb
$ echo $b
A környezeti változónak nemcsak konstans értéket adhatunk át, hanem egy függvény is akár:
$ C='() { echo $(($1+1)); }' bash -c 'C 2'
3
A gond ott van, hogy bár a függvény kódja véget ér a csukó kapcsos zárójelnél, a bash megengedi, hogy további kódrészletet írjunk oda, amit végrehajt:
$ C='() { echo $(($1+1)); }; echo vulnerable' bash -c 'C 2'
vulnerable
3
Ráadásul nemcsak akkor hajtja végre, ha meghívjuk a függvényt, hanem akkor is, ha nem:
$ C='() { echo $(($1+1)); }; echo vulnerable' bash -c 'echo x'
vulnerable
x
Ezután már elég jól érthető az az ellenőrző kód amit minden blog javasol:
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test
A :; igazából nem csinál semmit, de rövid és szintaktikailag helyes kódrészlet. Az env nem teljesen világos hogy miért kell, nekem működik anélkül is.
A fényképezőgépvezérlő programomban ( pkTriggerCord ) elég alacsony szinten kommunikálok a fényképezőgéppel, ioctl és scsi_generic segítségével lényegében direkt módon érem el a device fájlt ( pl. /dev/sdc ). Egy ideje feltűnt, hogy hiába tűnik úgy hogy van írási és olvasási jogom is /dev/sdc-hez, mégis csak akkor működik a program ha rootként futtatom.
Némi utánaolvasás után rájöttem (valahogy ez eddig nekem kimaradt), hogy egy ideje Linuxban is igen részletesen lehet szabályozni, hogy egy process milyen jogokkal bír, vagyis ha csak egyetlen speciális jogra van szükségünk, akkor nem kell root-ként ( vagy setuid rootként ) futtatni a programot, elég ezt az egyetlen jogot megadni. A jogok listáját itt nézhetjük meg.
Mint kiderült, nekem a CAP_SYS_RAWIO jog kell:
$ getcap pktriggercord-cli
$ setcap CAP_SYS_RAWIO+eip pktriggercord-cli
$ getcap pktriggercord-cli
pktriggercord-cli = cap_sys_rawio+eip
Vagyis először lekérdezve látszik, hogy a programnak nincs semmilyen különleges joga, majd miután beállítjuk a CAP_SYS_RAWIO-t a lekérdezés után már látszik a jog. Ezután már nem kell rootként futtatnom a programomat.
1. megjegyzés: A legtöbb helyen azt írják, a CAP_SYS_RAWIO olyan erős jogosultság, hogy ennyi erővel akár rootként is lehetne futtatni a programot, az sem lenne sokkal nagyobb biztonsági rés.
2. megjegyzés: Elég alattomos mellékhatás, hogy nem igazán látszik, hogy egy programnak valami különleges jogosultsága van. A setuid bitet mondjuk sokan felismerik, de az alap ls -l nem ír ki semmit amiből látszik a különleges jog. Szerencsére a színes ls piros színnel jelzi ezt.
Bár tisztában vagyok vele, hogy egy igazi parancssorrajongó monokrómban látja a világot, én szeretem, ha az ls parancs színeket használ. Az egyik fájlnak fura színe volt, utánanéztem hogy miként is színezi a fájlneveket az ls.
Kompatibilitási okokból az ls színezést külön kell bekapcsolni, de a legtöbb Linux disztribúció egy alias segítségével ezt bekapcsolja:
$ alias
ls alias ls='ls -F --color=auto'
A használt színeket az LS_COLORS környezeti változó határozza meg, egy nem túlzottan felhasználóbarát formátumot használva:
$ echo $LS_COLORS
rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.btm=01;32:*.bat=01;32:*.sh=01;32:*.csh=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.iso=01;31:*.jpg=01;35:*.jpeg=01;35:*.JPG=01;35:*.JPEG=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.ico=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.divx=01;35:*.xvid=01;35:*.3gp=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.gem=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:*.mp2=00;36:*.mod=00;36:*.xm=00;36:*.s3m=00;36:*.it=00;36:*.wma=00;36:*~=47;30:*.bak=47;30:*.swp=47;30:*.bck=47;30:*.bk=47;30:*.old=47;30:*.tmp=47;30:*.save=47;30:*.rpmsave=47;30:*.rpmnew=47;30:
A beállításhoz/lekérdezéshez többnyire a dircolors parancsot használják, ami egy érthetőbb formátumot is tud kezelni:
$ dircolors -p
TERM Eterm
TERM ansi
TERM color-xterm
TERM con132x25
TERM con132x30
TERM con132x43
TERM con132x60
TERM con80x25
TERM con80x28
TERM con80x30
TERM con80x43
TERM con80x50
TERM con80x60
TERM cons25
TERM console
TERM cygwin
TERM dtterm
TERM eterm-color
TERM gnome
TERM gnome-256color
TERM jfbterm
TERM konsole
TERM kterm
TERM linux
TERM linux-c
TERM mach-color
TERM mlterm
TERM putty
TERM rxvt
TERM rxvt-256color
TERM rxvt-cygwin
TERM rxvt-cygwin-native
TERM rxvt-unicode
TERM rxvt-unicode-256color
TERM rxvt-unicode256
TERM screen
TERM screen-256color
TERM screen-256color-bce
TERM screen-bce
TERM screen-w
TERM screen.Eterm
TERM screen.rxvt
TERM screen.linux
TERM st
TERM st-256color
TERM terminator
TERM vt100
TERM xterm
TERM xterm-16color
TERM xterm-256color
TERM xterm-88color
TERM xterm-color
TERM xterm-debian
# Below are the color init strings for the basic file types. A color init
# string consists of one or more of the following numeric codes:
# Attribute codes:
# 00=none 01=bold 04=underscore 05=blink 07=reverse 08=concealed
# Text color codes:
# 30=black 31=red 32=green 33=yellow 34=blue 35=magenta 36=cyan 37=white
# Background color codes:
# 40=black 41=red 42=green 43=yellow 44=blue 45=magenta 46=cyan 47=white
#NORMAL 00 # no color code at all
#FILE 00 # regular file: use no color at all
RESET 0 # reset to "normal" color
DIR 01;34 # directory
LINK 01;36 # symbolic link. (If you set this to 'target' instead of a
# numerical value, the color is as for the file pointed to.)
MULTIHARDLINK 00 # regular file with more than one link
FIFO 40;33 # pipe
SOCK 01;35 # socket
DOOR 01;35 # door
BLK 40;33;01 # block device driver
CHR 40;33;01 # character device driver
ORPHAN 01;05;37;41 # symlink to nonexistent file, or non-stat'able file
MISSING 01;05;37;41 # ... and the files they point to
SETUID 37;41 # file that is setuid (u+s)
SETGID 30;43 # file that is setgid (g+s)
CAPABILITY 30;41 # file with capability
STICKY_OTHER_WRITABLE 30;42 # dir that is sticky and other-writable (+t,o+w)
OTHER_WRITABLE 34;42 # dir that is other-writable (o+w) and not sticky
STICKY 37;44 # dir with the sticky bit set (+t) and not other-writable
# This is for files with execute permission:
EXEC 01;32
# List any file extensions like '.gz' or '.tar' that you would like ls
# to colorize below. Put the extension, a space, and the color init string.
# (and any comments you want to add after a '#')
# If you use DOS-style suffixes, you may want to uncomment the following:
.cmd 01;32 # executables (bright green)
.exe 01;32
.com 01;32
.btm 01;32
.bat 01;32
# Or if you want to colorize scripts even if they do not have the
# executable bit actually set.
.sh 01;32
.csh 01;32
# archives or compressed (bright red)
.tar 01;31
.tgz 01;31
.arj 01;31
.taz 01;31
.lzh 01;31
.lzma 01;31
.tlz 01;31
.txz 01;31
.zip 01;31
.z 01;31
.Z 01;31
.dz 01;31
.gz 01;31
.lz 01;31
.xz 01;31
.bz2 01;31
.bz 01;31
.tbz 01;31
.tbz2 01;31
.tz 01;31
.deb 01;31
.rpm 01;31
.jar 01;31
.war 01;31
.ear 01;31
.sar 01;31
.rar 01;31
.ace 01;31
.zoo 01;31
.cpio 01;31
.7z 01;31
.rz 01;31
.iso 01;31
# image formats
.jpg 01;35
.jpeg 01;35
.JPG 01;35
.JPEG 01;35
.gif 01;35
.bmp 01;35
.pbm 01;35
.pgm 01;35
.ppm 01;35
.tga 01;35
.xbm 01;35
.xpm 01;35
.tif 01;35
.tiff 01;35
.png 01;35
.ico 01;35
.svg 01;35
.svgz 01;35
.mng 01;35
.pcx 01;35
.mov 01;35
.mpg 01;35
.mpeg 01;35
.m2v 01;35
.mkv 01;35
.webm 01;35
.ogm 01;35
.divx 01;35
.xvid 01;35
.3gp 01;35
.mp4 01;35
.m4v 01;35
.mp4v 01;35
.vob 01;35
.qt 01;35
.nuv 01;35
.wmv 01;35
.asf 01;35
.rm 01;35
.rmvb 01;35
.flc 01;35
.avi 01;35
.fli 01;35
.flv 01;35
.gl 01;35
.dl 01;35
.xcf 01;35
.xwd 01;35
.yuv 01;35
.cgm 01;35
.emf 01;35
.gem 01;35
# http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions
.axv 01;35
.anx 01;35
.ogv 01;35
.ogx 01;35
# audio formats
.aac 00;36
.au 00;36
.flac 00;36
.mid 00;36
.midi 00;36
.mka 00;36
.mp3 00;36
.mpc 00;36
.ogg 00;36
.ra 00;36
.wav 00;36
# http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions
.axa 00;36
.oga 00;36
.spx 00;36
.xspf 00;36
.mp2 00;36
.mod 00;36
.xm 00;36
.s3m 00;36
.it 00;36
.wma 00;36
# backup formats
*~ 47;30
.bak 47;30
.swp 47;30
.bck 47;30
.bk 47;30
.old 47;30
.tmp 47;30
.save 47;30
.rpmsave 47;3
Ez sem túl olvasmányos, de ezt átnézve meg lehet érteni, mikor milyen színeket használ ls.
Találtam pár régi DV fájlt a gépemen, és kíváncsi voltam mikor készültek a felvételek. Emlékeztem arra, hogy a régien használt kino editor kiírta a felvétel dátumát is, vagyis valahol megvan az információ a fájlban.
Némi kutatás után rátaláltam a mediainfo projectre, ami sokféle média fájlból képes információt kiolvasni:
$ mediainfo kazetta1002.dv | grep -i date
Recorded date : 2003-12-22 15:49:09.000
Néhány évvel ezelőtt elég népszerűek voltak a merevlemezes DVD-felvevők. A kissé félrevezető név azt jelenti, hogy analóg TV-adásokat lehetett rögzíteni merevlemezre, majd később a felvételeket át lehetett venni DVD-re is. Komoly előrelépés volt egy ilyen a videómagnó után, de a digitális átállás után ezek is eléggé elavultak.
Nekem egy LG RH7500-as készülékem van amiben a DVD író/olvasó már nem működik rendesen, így a merevlemezen lévő felvételekhez nem férek hozzá (valamiért az összes ilyen eszköz közös jellemzője, hogy macerás a felvételekhez férni, még véletlenül sincs pl. hálózati csatlakozójuk).
Szétszedtem a készüléket, kiszereltem a merevlemezt. Mivel teljesen szabványos IDE HDD ezért csatlakoztatni tudtam a számítógéphez. Rögtön jelezte a gép, hogy nincs rajta partíciós tábla, de az adatokat lementettem egy fájlba:
$ dd if=/dev/sdc of=lg_7500.dat bs=1M
Beleolvasva a fájlba, úgy tűnik, hogy FAT32 partíció van rajta:
$ string lg_7500.dat | head -n 10
LGEINC
VOLUMELABE FAT32
LGEINC
VOLUMELABE FAT32
RRaA
rrAa
RRaA
rrAa
RRaA
rrAau`
Alaposabban megvizsgálva viszont látszik, hogy nem szabványos FAT32-ről van szó, hanem valami módosított verzióról, vagyis nem lehet egyszerűen felmountolni. Némi keresés után rátaláltam a fuse-lgefs projectre, amivel hozzá lehet férni az adatokhoz. Bár azt írja a feljesztő, hogy csak LG RHT-388H-ból kiszerelt merevlemezzel tesztelte, nagyszerűen működött LG RH7500-nál is:
$ lgefuse lg_7500.dat /mnt/test
$ ls -ltr /mnt/test
total 0
drwxr-xr-x 2 root root 0 Jan 1 2000 B/
drwxr-xr-x 2 root root 524288 Jan 1 2004 MEDIA/
-r--r--r-- 1 root root 1057282048 Feb 23 2007 00001407007d7223072720.str
-r--r--r-- 1 root root 119692 Feb 23 2007 00001407007d7223072720.idx
-r--r--r-- 1 root root 2353827840 Sep 7 2008 00020a04017d8730005001.str
-r--r--r-- 1 root root 751248 Sep 7 2008 00020a04017d8730005001.idx
-r--r--r-- 1 root root 2145730560 Aug 23 2009 00000a02007d9823205459.str
-r--r--r-- 1 root root 810684 Aug 23 2009 00000a02007d9823205459.idx
-r--r--r-- 1 root root 2623533056 Jan 15 2010 00000c01007da115212459.str
-r--r--r-- 1 root root 986884 Jan 15 2010 00000c01007da115212459.idx
-r--r--r-- 1 root root 1505107968 Jun 15 2010 00030a07027da613075121.str
-r--r--r-- 1 root root 142848 Jun 15 2010 00030a07027da613075121.idx
-r--r--r-- 1 root root 1162661888 Jan 12 2012 00000a1a007dc112100235.str
-r--r--r-- 1 root root 130292 Jan 12 2012 00000a1a007dc112100235.idx
-r--r--r-- 1 root root 9151928320 Sep 20 2013 00000a03007dd920151459.str
-r--r--r-- 1 root root 1022124 Sep 20 2013 00000a03007dd920151459.idx
-r--r--r-- 1 root root 8582496256 Nov 8 2013 00000a03007ddb08151459.str
-r--r--r-- 1 root root 958748 Nov 8 2013 00000a03007ddb08151459.idx
-r--r--r-- 1 root root 7336847360 Mar 28 17:20 00000a03007de328152430.str
-r--r--r-- 1 root root 820156 Mar 28 17:20 00000a03007de328152430.idx
-r--r--r-- 1 root root 9152591872 May 9 18:40 00000a03007de509151459.str
-r--r--r-- 1 root root 1022180 May 9 18:40 00000a03007de509151459.idx
-r--r--r-- 1 root root 1251153920 May 15 23:26 00000a06007de515211759.str
-r--r--r-- 1 root root 479428 May 15 23:26 00000a06007de515211759.idx
-r--r--r-- 1 root root 2450837504 May 18 23:09 00000b06007de518195759.str
-r--r--r-- 1 root root 923452 May 18 23:09 00000b06007de518195759.idx
-r--r--r-- 1 root root 1860700160 May 20 01:30 00000c04007de519224959.str
-r--r--r-- 1 root root 705020 May 20 01:30 00000c04007de519224959.idx
-r--r--r-- 1 root root 1784250368 May 21 00:26 00000d05007de520214959.str
-r--r--r-- 1 root root 676828 May 21 00:26 00000d05007de520214959.idx
A ritka ronda fájlnevek elsőre zavarónak tűnhetnek, a .str fájlok tartalmazzák a felvételeket, amiket pl. mplayer gond nélkül lejátszik.
A Dropbox általában egyszerűen a háttérben fut és egy ikonnal jelzi, hogy mi a státusza, de ha kell akkor parancssorból is tudjuk vezérelni:
$ dropbox status
Dropbox isn't running!
$ dropbox start
Starting Dropbox...Dropbox isn't running!
Done!
$ dropbox status
Starting...
$ dropbox status
Syncing (5 files remaining) Indexing 2 files...
$ dropbox status
Syncing (5 files remaining) Indexing 2 files...
$ dropbox status
Syncing (2 files remaining, 5 secs left) Uploading 2 files (278.3 KB/sec, 5 secs left)
$ dropbox status
Up to date
Kíváncsi voltam, vajon egy Kindle ( Keyboard 3G ) törlése ( factory reset ) után mennyi adat marad az eszközön. Vagyis valójában inkább arra, hogy eladás előtt elég-e a factory reset. Először rákérdeztem, de mivel túl konkrét választ nem kaptam végeztem egy kis tesztet.
A következő nagyon egyszerű script factory reset után is szépen kilistázza a Kindle korábbi könyveit:
$ dd if=/dev/sdc1 of=afterfactoryreset.dat bs=1M
$ strings afterfactoryreset.dat | grep -i '^mnt/us/documents' | rev | cut -d "." -f2- | rev | sort | uniq
mnt/us/documents/A Clash of Kings A Song of Ice a-asin_B000FC1HBY-type_EBOK-v_0
...
mnt/us/documents/Zendegi-asin_B003NE5TVU-type_EBOK-v_0
Ha epub fájlokat gyártunk, akkor nem elég ha 1-2 eszközön ellenőrizzük, hanem illik azt is vizsgálni, hogy megfelel-e a szabványnak.
Epub fájlokat validálhatunk az epubcheck használatával:
$ java -jar epubcheck-3.0.1.jar little_brother_doctorow_cory.epub
Epubcheck Version 3.0.1
Validating against EPUB version 2.0
ERROR: little_brother_doctorow_cory.epub/mimetype: Mimetype file should contain only the string "application/epub+zip".
ERROR: little_brother_doctorow_cory.epub/OPS/fb.opf(25,78): date value 'Mon May 05 20:23:43 +0200 2008' is not valid as per http://www.w3.org/TR/NOTE-datetime: [For input string: "Mon May 05 20"] is not an integer
WARNING: little_brother_doctorow_cory.epub/OPS/fb.ncx: meta@dtb:uid content '9bde0872-1ad5-11dd-b5b9-0018f369440e' should conform to unique-identifier in content.opf: 'urn:uuid:9bde0872-1ad5-11dd-b5b9-0018f369440e'
ERROR: little_brother_doctorow_cory.epub/OPS/fb.ncx(68,58): assertion failed: The "id" attribute does not have a unique value
ERROR: little_brother_doctorow_cory.epub/OPS/fb.ncx(89,58): assertion failed: The "id" attribute does not have a unique value
ERROR: little_brother_doctorow_cory.epub/OPS/fb.ncx(110,58): assertion failed: The "id" attribute does not have a unique value
ERROR: little_brother_doctorow_cory.epub/OPS/fb.ncx(131,58): assertion failed: The "id" attribute does not have a unique value
ERROR: little_brother_doctorow_cory.epub/OPS/fb.ncx(152,58): assertion failed: The "id" attribute does not have a unique value
ERROR: little_brother_doctorow_cory.epub/OPS/fb.ncx(740,59): assertion failed: The "id" attribute does not have a unique value
ERROR: little_brother_doctorow_cory.epub/OPS/fb.ncx(761,59): assertion failed: The "id" attribute does not have a unique value
ERROR: little_brother_doctorow_cory.epub/OPS/fb.ncx(782,59): assertion failed: The "id" attribute does not have a unique value
ERROR: little_brother_doctorow_cory.epub/OPS/fb.ncx(803,59): assertion failed: The "id" attribute does not have a unique value
ERROR: little_brother_doctorow_cory.epub/OPS/fb.ncx(824,59): assertion failed: The "id" attribute does not have a unique value
Check finished with warnings or errors
A program láthatóan igen szigorú, kipróbáltam pár hivatalos helyről származó epubbal, de mindegyikben talált kisebb-nagyobb hibát.
