Hosszú évek óta használom a which parancsot, de sosem merült fel bennem a kérdés, vajon mit ír ki, ha többször is szerepel a keresett program a PATH-on.
Alapesetben a legelső előfordulást írja ki:
$ which rails
/usr/bin/rails
A -a kapcsolóval viszont az összeset kiírja:
$ which -a rails
/usr/bin/rails
/bin/rails
/home/user/bin/rails
Utóbbi akkor nagyon hasznos, ha (kellően el nem ítélhető módon) több verziója is fent van a keresett programnak.
A nemrég indult http://ebooks.stackexchange.com/ oldalon tette fel valaki azt a kérdést, hogy miként lehet jpeg képekből epub fájlt gyártani parancssor használatával. A következő 2 soros scripet készítettem:
for i in *.jpg; do echo \![$i]\($i\); done > alljpgs.txt ebook-convert alljpgs.txt alljpgs.epub --formatting-type markdown
Valamiért nem sikerült 1 soros megoldást adnom, pedig próbálkoztam process helyettesítéssel. Ha valaki tud 1 soros megoldást, kérem írja meg!
Ha olyan témát szeretnénk lefényképezni ahol túl nagy az eltérés a legvilágosabb és a legsötétebb részek között, akkor a fényképezőgép korlátozott dinamikatartománya miatt az eredmény elég kiábrándító lesz. Ha a sötét részekre mérünk fényt akkor a világos részeknél csak egynemű fehér foltot kapunk, ha a világos részekre akkor a sötét részek lesznek teljesen feketék. Ha nagyon nagy a kontraszt akkor egyszerre lesz a kép sötét része teljesen fekete és a világos része teljesen fehér.
Ha expozíciósorozatot készítünk ( bracketing ) ahol az egyes képeknél eltér a záridő ( de minden egyéb paraméter megegyezik ), akkor már sokkal több esélyünk van arra, hogy minden részlet rendesen látszódjon, persze eltérő képeken:
Már csak össze kell illeszteni a különböző képeket. Az egyik lehetőség a HDR ( valójában inkább HDR + tonemapping ), de számomra szimpatikusabb az expozíciósorozat-egyesítés ( exposure fusion ). A különbséget itt nem részletezném, akit érdekel itt talál egy részletes leírást.
Egy kis scriptet készítettem, ami 3 DNG fájlt egyesít:
#!/bin/bash
x1=`printf '%04d' $1`;
x2=`printf '%04d' $(( $1+1 ))`;
x3=`printf '%04d' $(( $1+2 ))`;
efname=imgp${x1}_ef
ufraw-batch --temperature=5500 --out-type=png imgp${x1}.dng imgp${x2}.dng imgp${x3}.dng
align_image_stack -s 3 -a ais_imgp${x1}_ imgp${x1}.png imgp${x2}.png imgp${x3}.png
enfuse -o ${efname}.tif ais_imgp${x1}_*.tif
convert ${efname}.{tif,jpg}
exiftool -TagsFromFile imgp${x1}.png -all:all ${efname}.jpg
exiftool '-DateTimeOriginal>FileModifyDate' ${efname}.jpg
exiftool -P -keywords+="exposure fusion" ${efname}.jpg
rm ais_imgp${x1}_*.tif
rm ${efname}.tif
rm ${efname}.jpg_original
rm imgp${x1}.png imgp${x2}.png imgp${x3}.png
A script először konvertálja a DNG fájlokat png-re majd egymáshoz illeszti a képeket ( erre a lépésre nincs szükség ha stabil állványt használtunk ). A tényleges egyesítést enfuse végzi, majd átmásolom az exif adatokat, beállítom a fájl módosítási dátumát és az "exposure fusion" kulcsszót. A legvégén törlöm a felesleges fájlokat.
A script használata egyszerű, ha imgp0470.dng, imgp0471.dng, imgp0472.dng fájlokat akarom egyesíteni:
exposure_fusion.sh 470
Nem tudom ki emlékszik rá, de a DOS-os időkben elég macerás volt ékezetes karaktereket gépelni, ehelyett Alt-kódokkal lehetett a speciális magyar karaktereket elérni. Még mindig emlékszem rá, hogy Alt+160 volt az á, Alt+130 az é ( itt a többi kód ). Egy idő után elég gyorsan ment így a gépelés...
Szerencsére jó ideje nem kell így gépelnem, de nemrég egy speciális Unicode karaktert akartam begépelni bash parancssorban, és megint jól jött volna ez a módszer. Utánanéztem, és azt találtam, hogy CTRL-SHIFT-U lenyomása majd felengedése után a prompt egy aláhúzott u betűre vált ahol a hexadecimális Unicode kód beírásával írhatjuk be a speciális karaktereket.
Kipróbáltam, és a blog.hu editorában Firefox alatt is működik: şğç
Az előző bejegyzésben szerettem volna megmutatni a 29 input fájlt, de annyira azért nem voltak ezek fontosak, hogy 29 külön képet illesszek a bejegyzésbe, ehelyett egy montázst készítettem imagemagick montage parancsának segítségével:
montage -geometry 300x200+5+5 -label %f imgp*.jpg panorama_input.jpg
A képeket a parancs átméretezi 300x200-ra, 5 pixelnyi keretet rajzol közéjük, és a fájlok nevét írja a képek alá, majd automatikusan 6x5-ös mozaikba helyezi a képeket.
A hugin a legismertebb ingyenes panorámakép készítő program, ha szeretnénk, ezt is használhatjuk parancssorból. Én ebből a leírásból indultam ki és készítettem ezt a scriptet:
ufraw-batch --out-type jpg --overwrite --exposure=auto --temperature=5500 imgp*.dng
pto_gen -o project.pto imgp*.jpg
cpfind -o project.pto --multirow --celeste project.pto
cpclean -o project.pto project.pto
linefind -o project.pto project.pto
autooptimiser -a -m -l -s -o project.pto project.pto
pano_modify --canvas=AUTO --crop=AUTO -o project.pto project.pto
pto2mk -o project.mk -p prefix project.pto
make -f project.mk ENBLEND=enfuse all
convert prefix.tif panorama.jpg
A scriptet ebből a 29 input fájlból:
ezt a panorámát gyártja:
Egyetlen lényeges módosításom az ENBLEND=enfuse volt. Valamiért enblend nem ragasztotta össze rendesen a képeket, így helyette enfuse-t használtam.
A fenti script hugin-2012-t használja, nem a friss hugin-2013-at.
Mivel ez nem egy fotósblog, eltekintek annak az elemzésétől, hogy miért rossz ez a panorámakép.
A laptopom képernyőjének felbontása 1366x768, ami a legtöbb esetben elegendő ( most elegánsan ugorjuk át, hogy manapság már a legtöbb mobiltelefon felbontása is nagyobb ). Van azonban pár program ami nagyobb felbontást vár el, így az ablakok alja lelóg.
Talán a legegyszerűbb xrandr segítségével megoldani a problémát:
xrandr --output LVDS --panning 1366x1024
Ezután egy 1366x1024 pixeles virtuális képernyőn scrollozhatunk fel/le elég könnyen. A visszaállítás sem bonyolult:
xrandr --output LVDS --panning 1366x768
A szkeptikus blogon olvastam egy érdekes cikket a hamis pendrive-okról. Az ismeretlen helyről beszerzett, nagy kapacitású, gyanúsan olcsó pendrive-ok igen jelentős része hamisítvány. Fognak egy 8GB-os pendrive-ot (az sem baj, ha gyártási hibás), átprogramozzák, hogy 512GB-osnak tűnjön, majd jelentős haszonnal eladják. A legszebb az egészben, hogy ameddig 8GB-nál kevesebb adatot másolunk rá, addig tökéletesen működik, vagyis jó eséllyel még pozitív értékelést is küld a vásárló a csalónak.
A csaló pendrive-okkal egyidőben megjelentek a pendrive tesztelő programok is, én a cikkben is javasolt f3-at próbáltam ki, mivel ez parancssoros. A program 1GB-os fájlokkal másolja tele a pendrive-ot, majd ezeket olvassa vissza, ezzel ellenőrizve a működést:
$ ./f3write /run/media/user/4444-9999/
Free space: 1.91 GB
Creating file 1.fff ... OK!
Creating file 2.fff ... OK!
Free space: 0.00 Byte
Average writing speed: 3.89 MB/s
$ ls -l /run/media/user/4444-9999/
total 2002084
-rw-r--r-- 1 user user 1073741824 Oct 19 10:30 1.fff
-rw-r--r-- 1 user user 976392192 Oct 19 10:34 2.fff
$ ./f3read /run/media/user/4444-9999/
SECTORS ok/corrupted/changed/overwritten
Validating file 1.fff ... 2097152/ 0/ 0/ 0
Validating file 2.fff ... 1907016/ 0/ 0/ 0
Data OK: 1.91 GB (4004168 sectors)
Data LOST: 0.00 Byte (0 sectors)
Corrupted: 0.00 Byte (0 sectors)
Slightly changed: 0.00 Byte (0 sectors)
Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 13.51 MB/s
Ha valaki szeretné jobban megismerni a parancssor kezelését akkor persze lehet blogokat követni ( például ezt a blogot ), de a blogok jellegüknél fogva többnyire elég csapongóan írnak mindenféléről, így az alapokat nem feltétlenül így a legegyszerűbb megtanulni.
Számtalan ingyen elérhető programozással kapcsolatos könyvet találhatunk itt, közülük a bash, Linux, sed csoport könyveit érdemes alaposan átnézni.
A nemrég említett script egy másik érdekes használata a következő:
1. terminál:
$ mkfifo scriptpipe
$ script -f scriptpipe
2. terminál:
cat scriptpipe
Ezután az 1. terminálban dolgozhatunk tovább, és a 2. terminálban valós időben követhetjük az eseményeket.
Időnként hasznos elmenteni, hogy mit is dolgozunk egy terminálban, de egy videó mentése azért túlzásnak tűnik.
Egyszerűbb az util-linux csomagban található script programot használni:
script -t 2> timing.txt -a session.txt
A parancs hatására látszólag semmi sem történik, dolgozhatunk tovább, egészen addig amíg az exit parancsot be nem gépeljük ( vagy CTRL-D-t nem nyomunk ), ekkor 2 fájl keletkezik. session.txt tartalmazza magát a mentést, timing.txt pedig az időzítést, vagyis innen lehet tudni mit milyen gyorsan gépeltünk, az egyes programok mit mikor írtak ki a terminálba.
Ha vissza szeretnénk játszani a felvett anyagot, akkor a következőképpen tehetjük meg:
scriptreplay timing.txt session.txt
Nem igazán értem, hogy miért, de az én disztribúciómban util-linux csomag csak a script parancsot tartalmazza, scriptreplay-t nem. Van ennek egy perl verziója, innen töltöttem le.
A fortune az egyik leghaszontalanabb Unix parancs, a szerencsesütihez hasonlóan véletlenszerű rövid magvas/vicces mondatokat ír ki.
$ fortune
"My father? My father left when I was quite young. Well actually, he
was asked to leave. He had trouble metabolizing alcohol."
-- George Carlin
Igazából sosem jöttem rá miért hasznos, de több mint 30 éve része a Unixoknak.
Viszonylag ritkán, de előfordul, hogy parancssorból kell elérnünk a clipboard tartalmát. Az xclip használatával ez meglepően egyszerű. Néhány példa:
xclip alma.txt
A parancs alma.txt fájlt tartalmát másolja a clipboardra.
ls -l | xclip
Az ls -l parancs eredménye kerül a clipboardra.
xclip -o | less
A clipboard tartalmát kényelmesen megnézhetjük a less segítségével.
Bár már többször írtam a diff parancsról, valahogy eddig teljesen elkerülte a figyelmemet, hogy nemcsak fájlokat, hanem alkönyvtárakat is össze lehet hasonlítani a diff paranccsal.
Ha van két rettentő egyszerű alkönyvtárunk:
$ ls dir1
a.txt b.txt c.txt
$ ls dir2
a.txt c.txt
Ahol a.txt fájl tartalma megegyezik, de c.txt tartalma eltérő:
$ diff -q dir1/a.txt dir2/a.txt
$ diff -q dir1/c.txt dir2/c.txt
Files dir1/c.txt and dir2/c.txt differ
Akkor egyetlen egyszerű paranccsal összehasonlíthatjuk a két alkönyvtárat:
$ diff -rq dir1 dir2
Only in dir1: b.txt
Files dir1/c.txt and dir2/c.txt differ
Forrás: lifehacker
Az igen egyszerű
sudo !!
parancs segítségével az utolsó parancsot futtathatjuk újra root jogokkal ( feltéve persze ha sudo rendesen be van állítva).
A parancs a méltán népszerű commandlinefu All-time great listájának első helyét foglalja el.
A kettővel ezelőtti bejegyzéshez csatolt videó miatt szükségem volt a képernyőm egy részének rögzítésére. Ehhez recordmydesktopot használtam:
$ recordmydesktop -windowid $(xwininfo |grep "Window id:"|sed -e "s/xwininfo\:\ Window id:\ // ;s/\ .*//" ) --no-sound --no-cursor --fps 2 -o felvetel.ogv
Némi magyarázat:
Legutóbbi bejegyzésemhez egy nagyon egyszerű videót szerettem volna csatolni, de eléggé túlzásnak éreztem youtube-ra feltölteni, így animgifet használtam. Bár az animgif egy igen régi és elavult formátum amit már többször eltemettek, meglepő módon újra és újra visszatér.
Egy "rendes" videófájlból a következő módon gyártottam animgifet:
ffmpeg -i felvetel.ogv -pix_fmt rgb24 felvetel.gif
convert -layers Optimize felvetel.gif felvetel_opt.gif
A második parancsra azért van szükség, mert ffmpeg óriási méretű gifet gyárt, amit mindenképpen érdemes optimalizálni.
A pv ( pipe viewer ) és a cdialog együttes használatával elég könnyen tudunk egy hosszú műveletről folyamatos tájékoztatást adni.
A "nyers" pv parancs így néz ki:
$ pv nagy.pgn | gzip -c > nagy.gz
pv és cdialog összekötve:
$ (pv -n nagy.pgn | gzip -c > nagy.gz) 2>&1 | dialog --gauge "Tömörítés..." 10 70
Az eredmény egy ehhez hasonló dialógusablak:
Egyszer még nagyon régen írtam a zenity nevű programról, aminek használatával Gtk+ dialógusablakot lehet kezelni. Ez elég hasznos, ha egy hosszú scriptnél időnként értesíteni akarjuk a felhasználót arról, hogy mi is történik.
Ha nem szeretnénk ( vagy nem tudunk ) X-et használni, akkor karakteres alapon ( ncurses-re épülve ) is használhatunk dialógusablakokat a cdialog segítségével. A zenity-nél említett példák cdialog változatai:
Egyszerű ablak:
dialog --msgbox 'Befejeztem a hosszú műveletet.' 5 40
Egyszerű ablak timeouttal:
dialog --timeout 10 --msgbox 'Befejeztem a hosszú műveletet.' 5 40
Eldöntendő kérdés:
dialog --yesno "Biztos vagy benne?" 5 30 && echo "Munka"
Ha vegyesen szeretnénk karakteres és grafikus ablakokat használni, akkor elég kényelmetlen, hogy cdialog és zenity nem egyformán működik. Érdemes lehet zenity helyett Xdialogot használni, ami kompatibilis dialoggal.
A bejegyzést ez a friss LinuxJournal cikk inspirálta.
Korábban azt írtam, hogy xrandr segítségével könnyen és automatikusan felismertethetjük a külső monitort, akkor is, ha bootolás után csatlakoztatjuk:
xrandr --auto
Sajnos újabban úgy tűnik, hogy valamiért a parancs nem mindig működik, időnként elég furcsa üzemmódba állítja a külső monitort. Ha lekérdezem a monitorok jellemzőit, akkor látszik, hogy mi a baj:
$ xrandr
Screen 0: minimum 320 x 200, current 1366 x 1368, maximum 2646 x 2646
LVDS connected 1366x768+0+0 (normal left inverted right x axis y axis) 344mm x 193mm
1366x768 60.0*+
1280x768 60.0 +
1280x720 60.0 +
1024x768 60.0 +
1024x600 60.0 +
800x600 60.0 +
800x480 60.0 +
720x480 60.0 +
640x480 60.0 +
DFP1 connected 800x600+0+768 (normal left inverted right x axis y axis) 376mm x 301mm
1280x1024 60.0 +
1280x960 60.0 +
1280x800 60.0 +
1280x768 59.9 +
1280x720 60.0 +
1152x648 60.0 +
1152x864 60.0
1024x768 60.0
1024x600 60.0
800x600 60.3*
800x480 60.0
720x480 60.0
640x480 60.0
CRT1 disconnected (normal left inverted right x axis y axis)
A külső monitor ( DFP1 ) valamiért 800x600-as felbontásban megy (a csillagból látszik). Ráadásul a laptopmonitor alá teszi xrandr a külső monitort, ahelyett, hogy jobbra tenné, ahogy én szeretném.
Persze nemcsak automata üzemmódot támogat xrandr, így explicit módon is meg tudom adni az üzemmódot amit szeretnék:
xrandr --output LVDS --mode 1366x768 --output DFP1 --mode 1280x1024 --right-of LVDS
Ezután már rendben van minden:
$ xrandr
Screen 0: minimum 320 x 200, current 2646 x 1024, maximum 2646 x 2646
LVDS connected 1366x768+0+0 (normal left inverted right x axis y axis) 344mm x 193mm
1366x768 60.0*+
1280x768 60.0 +
1280x720 60.0 +
1024x768 60.0 +
1024x600 60.0 +
800x600 60.0 +
800x480 60.0 +
720x480 60.0 +
640x480 60.0 +
DFP1 connected 1280x1024+1366+0 (normal left inverted right x axis y axis) 376mm x 301mm
1280x1024 60.0*+
1280x960 60.0 +
1280x800 60.0 +
1280x768 59.9 +
1280x720 60.0 +
1152x648 60.0 +
1152x864 60.0
1024x768 60.0
1024x600 60.0
800x600 60.3
800x480 60.0
720x480 60.0
640x480 60.0
CRT1 disconnected (normal left inverted right x axis y axis)
Már többször írtam az mplayerről, többek között azért szeretem ezt a programot, mert billentyűzetről kényelmesen vezérelhető. Feltéve persze, ha megjegyezzük a szükséges billentyűparancsokat. Ehhez nyújt segítséget a következő ábra amit Mitesh Shah készített:
A képre kattintva Mitesh oldalán (néhány újabb kattintás után) nagyobb méretben is megnézhetjük a képet.
Több módszer is van aminek segítségével letölthetünk egy youtube videót, természetesen megoldható ez parancssorból is a youtube-dl program segítségével.
Miután felinstalláltam, először is frissítenem kellett a programot ( kétszer egymás után ):
youtube-dl --update
Ezután a letöltés már elég egyszerű:
youtube-dl "https://www.youtube.com/watch?v=OpaiGYxkSuQ"
A program képes egy félbemaradt letöltést folytatni, és youtube listákat is letölthetünk vele:
$ youtube-dl https://www.youtube.com/playlist?list=PLBDA2E52FB1EF80C9
[youtube] PL PLBDA2E52FB1EF80C9: Downloading page #1
[download] Downloading playlist: World History
[youtube:playlist] playlist 'World History': Collected 42 video ids (downloading 42 of them)
[download] Downloading video #1 of 42
...
Ha valójában nem elmenteni akarjuk a videót, csak a böngészőbe ágyazott flash player helyett a saját médialejátszónkat szeretnénk használni, akkor azt is megtehetjük:
mplayer -fs $(youtube-dl -g "https://www.youtube.com/watch?v=OpaiGYxkSuQ")
A -g kapcsoló miatt nem kell megvárni a teljes letöltést, hanem már közben is nézhetjük a videót.
Nevével ellentétben youtube-dl nemcsak youtube-ról tud letölteni, itt a támogatott oldalak listája.
Ha egy nagy fájlt szeretnénk az internetről letölteni akkor többnyire a nagyméretű fájl ( továbbiakban nagyfile.iso ) mellett találunk egy nagyfile.iso.md5 fájlt is, ami mindössze néhány bájtos, és segítségével a letöltött nagyméretű fájl integritását ellenőrízhetjük.
Egy fájl integritásának ellenőrzésekor legegyszerűbb egy CRC ellenőrzőösszeg számítása, ugyanakkor a módszer igen nagy hátránya, hogy csak a véletlenül előforduló hibák ellen véd. Vagyis azt ki tudjuk ezzel szűrni, ha a letöltött 4GB-os fájl néhány bájtja megsérül a letöltés során, de azt nem, ha valaki szándékosan módosítja úgy a fájlt, ha a CRC összeg ne változzon. Ha ennek ellenére valaki ezt szeretné használni, akkor a cksum paranccsal teheti meg.
Ha a szándékos károkozást is deketálni szeretnénk, akkor kriptográfiai hash függvényt kell használnunk. A legelterjedtebbnek nekem az MD5 tűnik.
MD5 fájlt így gyárthatunk:
$ md5sum nagyfile.iso > nagyfile.iso.md5
$ cat nagyfile.iso.md5
45371276b1406fb29640fa564d818e24 nagyfile.iso
Az ellenőrzés pedig így megy:
$ md5sum -c nagyfile.iso.md5
nagyfile.iso: OK
Érdemes azért tudni, hogy a legelterjedtebb MD5 függvényt már nem tekintik biztonságosnak, sőt az ennél jobbnak számító SHA1 ellen is létezik már elméleti törés. Használjunk inkább sha256 vagy sha512 függvényeket.
Halkan merem csak írni, de szerintem valójában csak a biztonság illúzióját nyújtják ezek a módszerek, legalábbis a letöltők 99%-a számára nem nyújtanak többet mint egy sima CRC ellenőrzés. Az egész módszer azt feltételezi, hogy az ellenőrzéshez használt fájl ( fenti példában nagyfile.iso.md5 ) már a birtokunkban van, és teljesen biztosak lehetünk a tartalmában. Ha egyszerre töltjük le nagyfile.iso nagyfile.iso.md5 fájlokat ugyanarról a szerverről, akkor ez nem igaz, ha valaki módosította nagyfile.iso-t, akkor módosíthatta nagyfile.iso.md5-öt is. Az md5 fájl ellenőrzését általában úgy oldják meg, hogy egy nagyfile.iso.md5.gpg fájlt is felmásolnak, aminek segítségével ellenőrizhetjük a nagyfile.iso.md5 fájlt. Feltéve, hogy kezünkben van az aláíró nyilvános kulcsa, amit nyilván megint nem szerencsés ugyanekkor ugyanarról a szerverről letölteni. Vagyis bár elvileg tényleg alaposan ellenőrizhetünk mindent, a valóságban a legtöbb ember letölt két fájlt, futtat egy md5sum -c parancsot és megnyugszik.
Ha egy véletlenszámra van szükségünk, akkor legegyszerűbb a $RANDOM környezeti változó használata, ami 0 és 32767 között ad egy véletleszámot:
$ echo $RANDOM
7161
$ echo $RANDOM
6322
Szinte minden weboldalon ahol írnak róla a kockadobást hozzák fel példának, így én is ezt teszem:
$ echo $(($RANDOM % 6 + 1))
5
$ echo $(($RANDOM % 6 + 1))
4
Ha nem egyszerűen egyetlen véletlenszámra van szükségünk, hanem pl. egy 1024 bájtból álló véletlen sorozatra, akkor /dev/urandom-ból érdemes dd-vel olvasnunk:
$ if=/dev/urandom of=urandom.dat bs=1024 count=1
1+0 records in
1+0 records out
1024 bytes (1.0 kB) copied, 0.000456885 s, 2.2 MB/s
Nyilván felmerül a kérdés, miért /dev/urandom-ot használunk, miért nem /dev/random-ot. Próbáljuk meg azt:
$ dd if=/dev/random of=random.dat bs=1024 count=1
0+1 records in
0+1 records out
16 bytes (16 B) copied, 8.0245e-05 s, 199 kB/s
Meglepő, de hiába kértem 1 db. 1024 bájtos adatcsomagot, csak 16 bájtot kaptam. Kérjünk inkább 1024 db. 1 bájtos csomagot:
$ dd if=/dev/random of=random.dat bs=1 count=1024
1024+0 records in
1024+0 records out
1024 bytes (1.0 kB) copied, 99.2821 s, 0.0 kB/s
Ezzel már sikerült 1024 bájt kiolvasása, de több mint 1 percet kellett az eredményre várni. Ha 1GB véletlen adatra lenne szükségünk, akkor reménytelen lenne kivárni ameddig összegyűlik az adat.
A /dev/random és /dev/urandom közti különbségről több helyen is írnak, a lényeg az, hogy /dev/random "igazibb" véletlenszámokat ad az egyes hardverelemek entrópiáinak felhasználásával, de cserébe hamar elfogynak a rendelkezésre álló bájtok, ilyenkor vár addig ameddig újra össze nem gyűlik megfelelő mennyiségű adat. Ezzel szemben /dev/urandom folyamatosan képes véletlenszámokat adni, cserébe az alacsonyabb minőségért. Az esetek többségében a /dev/urandom is megelelő számunkra, hacsak nem valami komoly kriptográfiai célra kellenek az adatok.
Manapság a legtöbb számítógép képes arra, hogy "kikapcsolt" állapotban is figyelje a hálózatot, és megfelelő jel esetén felébredjen. Igen hasznos ez a képesség, ha egy távoli számítógépet időnként el szeretnénk érni, de mégsem szeretnénk folyamatosan bekapcsolva hagyni.
A felébresztésnek több módja van, a wol programmal parancssorból is felébreszthetünk egy távoli számítógépet:
wol AA:BB:CC:DD:EE:FF
Paraméternek a gép MAC-címét kell megadnunk.
Arra azért figyeljünk oda, hogy a parancs nem várja meg, hogy a távoli gép feléledjen, vagyis legalább egy sleep-et tegyünk a scriptünkbe a parancs után.
