E adevărat, folosite greșit pot face pagube, niște exemple:
rm -rf /* = șterge forțat tot ce conține partiția /
dd if=/dev/zero of=/dev/sda = scrie discul /dev/sda cu 0-uri, pierdeți tot conținutul
mkfs.ext4 /dev/sda1 = formatează partiția /dev/sda1 în ext4
Dar nu sunt singurele posibilități de-a ne ”șifona” serios sistemul, foarte multe comenzi comune, banale utilizate greșit fac chestii similare...
Hai să vedem un exemplu, ls:
ls -l = listează, afișează conținutul directorului curent sau al celui pasat ca argument (ls -l Documents va afișa conținutul directorului Documents)
ls -l > list.txt = scrie conținutul directorului curent în fișierul list.txt, dacă fișierul nu există este creat, dacă fișierul are conținut acesta va fi suprascris
ls -l >> list.txt = idem, dar outputul comenzii ls -l va fi adăugat la finalul fișierului, nu se pierde conținutul existent
ls -l > list.txt ; cat list.txt = scrie conținutul directorului în fișierul indicat și apoi afișează conținutul fișierului (conținut care de fapt coincide cu cel al directorului curent...), deci outputul e afișat în terminal și salvat în fișierul list.txt
Chestii inofensive, banale, nu? Dar ce credeți că va face comanda următoare?
ls -l > /boot/grub/grub.cfg
Nu mare lucru dacă nu sunteți logat ca root, nu ați avea permisiuni de scriere, dar ca root sau precedată de sudo va suprascrie /boot/grub/grub.cfg... Destinația ar putea fi orice fișier important, /etc/fstab, /etc/pcman.conf, etc, rezultatele nu ne-ar plăcea deloc... :D
Problema o constituie redirecționarea outputului comenzii ls către un anume fișier (unul important, de sistem) și suprascrierea acestuia! Similar putem greși cu wc, cat, etc.
Un alt caz este tee.
ls -l | tee list.txt = va direcționa outputul comenzii ls -l către fișierul list.txt, dacă fișierul nu există va fi creat, iar outputul scris în fișier, inofensiv
tee * = va șterge conținutul tuturor fișierelor din directorul curent, dacă directorul curent este ~ sau /, sau dacă pasăm un director important ( sudo tee /* sau tee ~/.*) pierdem toate fișierele importante, mai exact conținutul acestora!
Tocmai am pățit o asemenea chestie cu tee, nu ceva serios, eu testez comenzi neclare, dubioase, potențial periculoase în partiția mea pentru teste, sau măcar în locații speciale, neimportante, creez un director de test, cu sud-directoare și fișiere și văd ce se întâmplă. Evident că e indicat să ne abținem de la așa ceva, dar cum eu sunt curios și mai ales cum am un sistem de lucru (Arch) și întotdeauna am și o distribuție în teste (care oricum va fi înlocuită curând) pot testa pe aceasta din urmă, am învățat destule așa...
La fel de important e să nu abuzăm de permisiunile de root și să avem un backup al sistemului.
Problema a fost neînțelegerea corectă a modului de lucru al tee, aplicație folosită pentru a citi date/ output și a-l afișa pe display și a-l stoca și într-un fișier concomitent. Greșeala mea a fost că am presupus că dacă nu există output care să fie citit (datele citite de tee din stdin, care date?) nu se întâplă nimic, asta datorită lipsei parametrilor necesari, adică o comandă incompletă... :( Assumption is the mother of all FUCK UPS!!! De fapt tee citește ”nimic”, scrie nimic!
Faptul că folosisem anterior tee nu m-a scutit de greșeli, folosisem comanda într-un mod aparent diferit (ls -l | tee ~/list.txt ~/Documents/list.txt sau wc * | tee -a ~/count.txt | sort).
În fine, nu vă bucurați prematur, singura ”rană” am căpătat-o în ego (orgoliu ar zice vreo doi tipi pe care-i cunosc), iar cunoștințele căpătate astfel sunt mai importante decât ”umilința” de moment sau (evident) decât 3-4 fișiere de sacrificiu!
RECOMANDĂRI:
1- nu rulați comenzi pe care nu le cunoașteți/ înțelegeți;
2- nu executați comenzile ca root sau cu sudo;
3- nu faceți probe pe sistemul de lucru, principal, testați acele comenzi pe un sistem de sacrificiu, o distribuție aflată în teste;
4- dacă nu aveți sistem de rezervă, dar nu vă puteți abține verificați mai întâi cu man comanda sau comanda --help ce anume face acea comandă; dacă tot nu lămuriți căutați și pe net materiale/ tutoriale despre comanda cu pricina;
5- înlocuiți la parametri directoarele/ fișierele importante cu unele de test; chiar și pe mașina de test procedați la fel; de exemplu în loc de / pasați ~/test, în loc de /* puneți ~/test/fișier-neimportant;
6- nu uitați: înainte de ”teste” salvați-vă directoarele/ fișierele mai importante pe discuri externe/ dvd-uri/ servicii de stocare online; faceți backup sistemului, operație indicată a fi făcută periodic;
7- așteptați-vă la ce e mai bine, dar pregătiți-vă de ce e mai rău, shit happens...
PS: În mod normal nimeni nu prea ascultă de sfaturi de astea, așa că dacă pățiți ceva urât (sau ați pățit), spuneți-mi și mie într-un comentariu, măcar cu atât să mă aleg și eu. Același lucru și în privința posibilelor sugestii/ recomandări.
Niciun comentariu:
Trimiteți un comentariu