Можете ли вы на самом деле использовать терминал для сбоя компьютера?


48

Люди, которые не понимают Терминал, часто боятся использовать его, опасаясь, что они могут испортить свою команду и сломать компьютер. Те, кто знает Terminal, лучше знают, что это не так - обычно Terminal просто выдаст ошибку. Но есть ли на самом деле команды, которые сломают ваш компьютер?

ВНИМАНИЕ: вы можете потерять данные , если вы наберете эти или копировать вставить, особенно sudoи rmкоманды.


Какой-то парень случайно вытер все компьютеры своей компании в одну строку, я видел это на этом сайте пару лет назад, это было подделкой, но это все же могло легко произойти. Я свяжусь, если смогу найти.
Ноа Кристино

7
Терминал - это просто интерфейс командной строки для запуска программ. Это альтернатива графическому пользовательскому интерфейсу . Вы можете запускать произвольные программы из любой. Поэтому ваш вопрос не имеет большого смысла; вместо этого вы должны спросить: можете ли вы сломать компьютер, запустив программу?
Джеймсдлин

Что вы подразумеваете под "сбой"? Команды, запускаемые в терминале, часто бывают мощными и часто «делают то, что вы говорите, а не то, что вы имеете в виду», не спрашивая, в отличие от большинства команд графического интерфейса Mac OS X. Но если вы намеренно не попытаетесь , вы вряд ли сломаете машину. (Однако я могу придумать несколько способов сделать это намеренно)
Джош

1
Вставка команд из Интернета может быть очень опасной . Независимо от возможности повесить машину. Хотя вводить команды, которые вы понимаете хотя бы смутно, не должно быть опасно. В противном случае множество способов прикрутить ваш компьютер. Это похоже на выбор случайных настроек конфигурации системы в графическом интерфейсе, но в графическом интерфейсе, по крайней мере, возможности более ограничены. Опасность вставки команд - текст, который вы визуально видите скопированным, может отличаться от фактического скопированного текста, поэтому он может содержать смешанные вредоносные команды.
Акостадинов

@ иσαнcяişтiпσ Может быть serverfault.com/questions/769357/recovering-from-a-rm-rf
wythagoras

Ответы:


51

Один из способов сбить компьютер - запустить так называемую вилочную бомбу .

Вы можете выполнить его в Unix-системе:

:(){ :|: & };:

Это команда, которая будет рекурсивно запускать процессы до тех пор, пока ОС не станет настолько загруженной, что больше не будет реагировать на какие-либо действия.


49
@bunyaCloven, если я правильно понимаю вашу команду, то это команда для удаления всех папок без запроса , что очень опасно, если она работает . Я хотел бы, чтобы вы написали предупреждение об этом.
Андрей Т.

80
@AndrewT. Люди не должны просто вводить случайные команды, которые они находят в Интернете, все так или иначе. (особенно в теме под названием «
Джон Гамильтон

34
ОП попросил сбой из терминала, а не вайп.
Piersb

16
Вилочная бомба фактически нанесет минимальный ущерб Mac OS X, поскольку она имеет верхние границы для числа процессов.
GDP2

7
@bunyaCloven замените на ;a, &и вы получите возможность удалить все файлы и ответную бомбу одновременно, и посмотрите, что первым сломает систему!
Музер

41

Не уверен, что вы имеете в виду по поводу «сбоя» компьютера - если вы перефразируете его словами «сделать компьютер непригодным для использования», тогда да. Конечно, все, что нужно, - это единственная случайная команда - просто момент, когда вы не думаете четко о том, что вы делаете, подобно тому, когда вы говорите, не задумываясь, и ущерб может быть огромным и почти мгновенным. Классический пример:

$ sudo rm -rf /

Если вы дадите этой команде выполнить хотя бы одну секунду, это может стереть достаточно с вашей системы, чтобы сделать ее не загружаемой, и, возможно, привести к необратимой потере данных. Не делай этого.


2
И просто для того, чтобы объяснить, почему я хотел уточнить перефразировку: «сбой» компьютера в традиционном смысле - чтобы он заблокировался, - вам нужно дать ЦПУ достаточно работы, чтобы он не мог ответить. своевременно выполнять другие задания .. например, обновлять графику и перемещать курсор, например. Я уверен, что есть способ сделать это из командной строки.
Harv

6
@DonielF -rозначает рекурсивное удаление файлов в каталоге. -fозначает «принудительно», как «не запрашивать подтверждение», независимо от прав доступа к данному файлу. /является корневым каталогом файловой системы, что означает, что она уничтожит все и вся, кроме, возможно, некоторых специальных файлов, которые не ведут себя как типичные файлы. Кроме того, вам будет довольно сложно найти краткую команду, которая приведет к краху вашей системы без прав root / admin.
GDP2

11
Я попытался rm -rf /некоторое время назад, и rmсказал, что если вы хотите удалить root, то используйте такой-то флаг. Данные не были потеряны. Похоже, сейчас есть защита от слепого бега rm -rf /.
alexyorke

27
--no-preserve-root флаг требуется с 2006 года для того, чтобы это работало как задумано
Encaitar

6
Вот реальный случай, в котором это действительно произошло - rm -rf действительно похожее на юридическое, которое пошло совсем не так: /
mgarciaisaia

30

Предположим, вы не знаете, что делаете и пытаетесь сделать резервную копию жесткого диска

dd if=/dev/disk1 of=/dev/disk2 

Хорошо, если вы смешаете их (переключитесь, если и из), он перезапишет свежие данные со старыми данными, без вопросов.

Подобные путаницы могут случиться с утилитой архива. И, честно говоря, с большинством утилит командной строки.

Если вам нужен пример смешивания одного символа, который приведет к краху вашей системы, взгляните на этот сценарий: вы хотите переместить все файлы в текущем каталоге в другой:

 mv -f ./* /path/to/other/dir

Давайте примем тот факт, что вы научились использовать ./для обозначения текущего каталога. (Да) Хорошо, если вы пропустите точку, она начнет перемещать все ваши файлы. Включая ваши системные файлы. Тебе повезло, что ты этого не сделал. Но если вы где-то читаете, что с помощью 'sudo -i' вам больше никогда не придется вводить sudo, то вы вошли в систему как пользователь root. И теперь ваша система пожирает себя на ваших глазах.

Но опять же я думаю, что такие вещи, как перезапись моих драгоценных файлов кода мусором, потому что я испортил один символ или из-за того, что я перепутал порядок параметров, создают больше проблем.

Допустим, я хочу проверить ассемблерный код, который генерирует gcc:

gcc -S program.c > program.s

Предположим, у меня уже была программа.s, и я использую завершение TAB. Я спешу и дважды забываю:

gcc -S program.c > program.c

Теперь у меня есть код на ассемблере в моем program.c и больше нет кода на c. По крайней мере, для некоторых это реальная неудача, а для других - время начала с нуля.

Я думаю, что это те, которые принесут реальный "вред". Мне действительно все равно, если моя система падает. Я бы позаботился о том, чтобы мои данные были потеряны.

К сожалению, это ошибки, которые нужно будет сделать, пока вы не научитесь пользоваться терминалом с надлежащими мерами предосторожности.


16
Ваше последнее замечание - одна из многих причин, по которым все должны использовать контроль версий
Даррен Х.

4
Однажды я уничтожил программу, над которой работал, gcc program.c -o program.cименно благодаря завершению вкладки. После этого я научился религиозно использовать контроль версий.
nneonneo

2
Лучший ответ на данный момент - публикация законно выглядящих команд, которые могут быть результатом простой опечатки, но при этом могут привести к серьезному ущербу.
gaazkam

1
«Теперь у меня есть код на ассемблере в моей программе. У тебя ничего нет. Перенаправление обрезало файл до того, как GCC даже открыл его.
Муру

1
О, чувак, я действительно очень рад, что они добавили это улучшение пользовательского интерфейса в GCC. Со времени моей последней ошибки прошло много времени, но приятно видеть, что в следующий раз у меня будет небольшая защита.
nneonneo

28

Причинение паники ядра более похоже на сбой, чем другие ответы, которые я видел здесь до сих пор:

sudo dtrace -w -n "BEGIN{ panic();}"

(код взят здесь, а также найден в собственной документации Apple )

Вы также можете попробовать:

sudo killall kernel_task

Я не проверял, что второй там действительно работает (и я не собираюсь этого делать, потому что сейчас у меня действительно есть работа).


2
Только что попробовал второй в 10.12.3 ВМ, и он просто говорит:No matching processes were found
Александр О'Мара

3
Кроме того, первый, похоже, не работает, по крайней мере, если SIP включен,dtrace: system integrity protection is on, some features will not be available dtrace: description 'BEGIN' matched 1 probe dtrace: could not enable tracing: Permission denied
Александр О'Мара

@ AlexanderO'Mara Не очень удивлен вашими результатами по второй команде; Я подумал, что Mac OS X не позволит вам просто так закрыть процесс ядра. Также следует ожидать результатов для первой команды, что dtraceбыло эффективно кастрировано SIP.
GDP2

1
kernel_taskэто не нормальный процесс. Это бессмертно; Его нельзя убить, кроме как из-за собственной ошибки (которая называется KP и приводит к поломке всей машины). kernel_taskPID номинально равен 0, но если вы kill(pid, sig)передадите его системному вызову, на странице руководства будет указано, что если pidравно 0, то sigотправляется каждому процессу в группе процессов вызывающего процесса. , Таким образом, вы просто не можете отправить kernel_taskсигнал.
Iwillnotexist Idonotexist

@IwillnotexistIdonotexist Да, я подумал, что так будет; спасибо за информацию, хотя. Хорошие вещи, чтобы иметь в виду.
GDP2

19

Современные macOS сильно затрудняют сбой вашей машины как непривилегированного пользователя (то есть без использования sudo), поскольку системы UNIX предназначены для работы с тысячами пользователей, не позволяя ни одному из них разрушить всю систему. Так что, к счастью, вам, как правило, нужно будет запросить, прежде чем делать что-то, что разрушает вашу машину.

К сожалению, эта защита относится только к самой системе. Как показывает xkcd, есть множество вещей, которые вас волнуют, и которые не защищены защитой целостности системы, привилегиями root или запросами пароля:

XKCD 1200

Итак, вы можете набрать массу вещей, которые просто разрушат вашу учетную запись пользователя и все ваши файлы, если вы не будете осторожны. Несколько примеров:

  • rm -rf ${TEMPDIR}/*, Это кажется вполне разумным, пока вы не поймете, что переменная среды записана TMPDIR. TEMPDIRобычно не определено, что делает это rm -rf /. Даже без sudoэтого, это удачно удалит все, на что у вас есть разрешения на удаление, которые обычно включают всю вашу домашнюю папку. Если вы позволите этому работать достаточно долго, он также будет уничтожен на любом диске, подключенном к вашей машине, так как у вас обычно есть права на запись для них.
  • find ~ -name "TEMP*" -o -print | xargs rm, findобычно находит файлы, соответствующие определенным критериям, и распечатывает их. Без -oэтого он делает то, что вы ожидаете, и удаляет каждый файл, начиная с TEMP*( если у вас нет пробелов в пути ). Но -oозначает «или» (не «вывод», как это делается для многих других команд!), Заставляя эту команду фактически удалить все ваши файлы. Облом.
  • ln -sf link_name /some/important/file, Я иногда получаю неправильный синтаксис этой команды, и она довольно успешно перезапишет ваш важный файл бесполезной символической ссылкой.
  • kill -9 -1 убьет все ваши программы, довольно быстро выйдет из системы и, возможно, приведет к потере данных.

3
К вашему сведению (для тех, кто читает это), findесть -deleteаргумент, который намного безопаснее, чем xargs rm
Джош

Является ли современный MacOS действительно более устойчивым к сбоям? Большинство этих систем предназначены для одного пользователя. У них действительно есть вменяемые maxprocs / cpulimits? Можете ли вы предоставить ссылку?
user2497

1
Вы, из всех людей, хорошо знаете, какой ущерб ln -sfможет нанести ... и как оправиться от него :-)
Ивилнотексист Идонтотексист

1
@Josh: спасибо за указание на это. И, в общем случае, следует использовать find -print0 | xargs -0для безопасной обработки странных символов в именах файлов.
nneonneo

1
Согласовано. Более полезный совет xargs: <whatever> | xargs echo <something>сначала используйте , чтобы просмотреть, какие команды на самом деле будет запускать xargs. xargs является отличным примером того, почему CLI настолько мощен: вы можете работать со многими, многими элементами одновременно без надоедливого подтверждения и ручного удержания ... просто убедитесь, что вы говорите ему делать то, что вы хотите.
Джош

16

Еще одно, что вы можете сделать (что я сделал по ошибке раньше):

sudo chmod 0 /

Это сделает всю вашу файловую систему (что означает все команды и программы) недоступными ... кроме как пользователю root. Это означает, что вам нужно будет войти в систему напрямую как пользователь root и восстановить файловую систему, НО вы не можете получить доступ к sudoкоманде (или любой другой команде, в этом отношении). Вы можете восстановить доступ к командам и файлам, загрузившись в однопользовательском режиме, смонтировав и восстановив файловую систему с помощью chmod 755 /.

Если это делается рекурсивно, chmod -R 0 /то это сделает систему непригодной для использования. Надлежащим решением на этом этапе является использование Дисковой утилиты из раздела восстановления для восстановления прав доступа к диску . Вам может быть лучше просто восстановить снимок или резервную копию вашей файловой системы, если это было выполнено рекурсивно.


8
«Вы можете исправить это ... chmod 755 /» - Нет, вы не можете. Многим файлам требуются разные разрешения от 755, либо для безопасности, либо для работы вообще. chmod 755 /оставит вашу систему небезопасной и сломанной тонкими способами. Единственное полное восстановление chmod 0 /- через восстановление моментального снимка, восстановление резервной копии и / или переустановку.
marcelm

2
@marcelm Хороший вопрос. Мое предложение было только восстановить доступ к командам, а не как постоянное исправление. Я обновил свой ответ, чтобы отразить это. Насколько я знаю, chmod не является рекурсивным, если вы не используете -Rфлаг - поэтому я подумал, что разрешения подкаталогов не будут затронуты?
musicman523

5
@marcelm вы правы, но показанная команда не является рекурсивной, поэтому /влияет только на нее .
Андреа

Я однажды sudo chmod -R 700 /приобрел новый компьютер, полагая, что это будет намного безопаснее, если я сделаю это. Удивительно, но он загрузился и закончился пустой строкой меню и пустым рабочим столом. Ничто другое не сработало, но разрешения для восстановления дисковой утилиты раздела восстановления фактически позволили установить почти все правильно!
nneonneo

2
Дисковая утилита @marcelm имеет опцию «Fix Permissions», которая должна исправить это без полного восстановления системы
Josh

10

Ответы на этот звонок sudoследует считать недействительными. Они уже предполагают административный доступ к системе.

Попробуй perl -e 'exit if fork;for(;;){fork;}'. OSX может иметь некоторую защиту от этого сейчас. Если есть яблочный пузырь, спрашивающий, хотите ли вы прекратить приложение терминала и подпроцессы, вы (почти) хороши.

while true ; do cat /dev/zero > /dev/null & doneтоже очень удобно, особенно если у вас нет perl.

for i in 1 2 3 4 ; do cat /dev/zero > /dev/null & doneпросто сделаю небольшой забавный тест загрузки процессора. Очень хорошо подходит для проверки, соответствуют ли ваш радиатор и вентилятор.


Это известно как Fork Bomb и, вероятно, сделает систему непригодной для использования (может рассматриваться как «сбой»), но вряд ли вызовет какой-либо постоянный ущерб. Но это противно!
Джош

@ Джош "но вряд ли нанесет непоправимый урон" За исключением любой открытой в данный момент несохраненной работы.
Рейраб

@reirab Джош добавил «все возможное» к своему заявлению. Но MacOS в основном для редактирования фотографий и видео сейчас. Программы Adobe не имеют автоматического автосохранения?
user2497

1
Кроме того, несохраненная работа всегда находится под угрозой, пока не будет сохранена. Если ваш компьютер стал непригодным для использования, вы не сможете сохранить все, что у вас открыто :)
Josh

@ Джош MacOS так легко сохранить вещи. Это всегда 🍎-S. Вы не должны были писать «вероятно» user
user2497

7

Конечно, убедитесь, что у вас есть резервная копия и сохраните все файлы, которые вам нужны, затем введите halt

Предполагая, что вы затем используете sudoroot, Mac рухнет.

Самый большой риск из командной строки - потеря данных. Интерфейс macOS разработан на протяжении десятилетий, чтобы не удивлять людей и не уничтожать их данные, настройки или приложения. Графический интерфейс macOS также существует для удаления кривой обучения (крутой) к безопасности и освоения сценариев оболочки.

Вы теряете эти средства защиты, поэтому я предупреждаю людей, начинающих с терминального приложения или ssh. Если у вас есть резервная копия, которая, как вы знаете, работает, и у вас есть время, уверенность / умение выполнить восстановление, вам следует погрузиться в нее, изучить и даже сломать вещи.


3
Вы сказали: «... и даже сломать вещи», что является хорошим вариантом для того, чтобы делать рискованные вещи на виртуальной машине. :)
user3439894

1
Как будет эта катастрофа? Это просто немедленно выключает систему. Он даже очищает буферы ядра, чтобы не было (сохраненных) потерь данных. developer.apple.com/legacy/library/documentation/Darwin/…
Джош

7
sudo kill -9 -1  

Я случайно выполнил kill -9 -1Perl-скрипт, работающий от имени пользователя root. Это было так же быстро, как тянуть за шнур питания. При перезагрузке сервер произвел проверку файловой системы и продолжил работать должным образом.

Я никогда не пробовал эту sudo kill -9 -1команду в командной строке. Это может не сработать, потому что идентификатор процесса «-1» означает «убить все процессы, принадлежащие группе процессов вызывающего».

Не уверен, что если с sudo, это также означает init и все ядро ​​... Но если вы являетесь пользователем root, kill -9 -1определенно сделаете немедленную остановку - точно так же, как отключение шнура питания. Кстати, в лог-файлах ничего не появится, потому что эта команда - самый быстрый убийца на западе!

Собственно, чтобы прийти в себя, я пошел к нашим сисадминам и рассказал им, что я сделал. Они сделали полную перезагрузку, потому что не было возможности войти на этот сервер (RHEL6).

A kill -9 -1как root убивает каждый процесс, который запускается как root. То есть то есть sshd. Это сразу же вышло из системы и не позволило никому войти снова. Любой процесс, запущенный init, включая init, был убит, если они не изменили UID или GID. Даже вход через последовательную консоль больше не был возможен. ps -eaf | grep rootпоказывает некоторые причудливые процессы, которые, если они реагируют на SIGKILL по умолчанию, в значительной степени остановят даже простую запись в HD.

Я не буду пробовать это сейчас на своем ноутбуке :-) Я не достаточно любопытен, чтобы узнать, действительно ли kill -9 165([ext4-rsv-convert]) перестанет писать на HD.


Вы не можете «убить» ядро, и это не должно вызывать проверку файловой системы. Как вы оправились от ситуации? Вы сделали жесткую перезагрузку? Потому что это, вероятно, и стало причиной проверки файловой системы :)
Джош

Ваш отредактированный ответ имеет смысл. Вы не можете на самом деле initнормально убить , но вы можете убить все сессии gettys и SSH и сделать машину непригодной для использования. Магия SysRq должно было позволить для чистой перезагрузки, но это часто бывает проще всего отключить питание и полагаться на журнал FS :)
Джош

5

Да, вы можете полностью разрушить вашу систему. Случайное выполнение чего-то с sudoпривилегиями является одним из примеров, который был опубликован, будь то забывание нескольких символов, которые инструктируют терминал делать что-то совершенно другое, чем вы предполагали. rming /вместо вместо /tmp/\*5 символов. Поместив пробел в неправильном месте, можно сделать что-то совершенно другое. В других случаях, казалось бы, в инструкциях с хорошим смыслом может быть скрыт вредоносный код. Некоторые люди в Интернете очень хорошо запутывают код.

Есть также команды, которые, используя html, могут сделать шрифт нулевого размера, так что при копировании в буфер обмена что-то совершенно безобидное может фактически установить чье-то git-репо в качестве надежного источника и загрузить вредоносное ПО.

И есть команды, которые вы можете запускать, которые открывают вас для использования, или которые могут быть совершенно правильными, но удаляют важные файлы или программы или повреждают ваш диск. На самом деле, неправильное использование инструментов может сделать что-то столь же простое, как случайная запись в загрузочный сектор или на верхнюю часть диска, или множество других проблем.

Примером чего-то менее разрушительного, что не было опубликовано, является открытие двоичных файлов в vi. Если вы когда-либо пробовали это, вы будете знать, что он может испортить ваш терминал до такой степени, что он будет непригоден до тех пор, пока он не будет reset.

В качестве альтернативы, есть команды, которые будут тормозить вашу машину, например:

yes >> /dev/null & yes >> /dev/null & yes >> /dev/null & yes >> /dev/null & 

Вы можете попробовать это, он не будет наносить урон, но затормозит ваш процессор, и вам придется убивать каждый процесс, который вы породили.

При этом в вычислительной технике принято считать, что вы не можете приготовить омлет, не разбив несколько яиц. Вы должны быть осторожны в терминале, но единственный способ стать лучше в использовании ОС - это учиться и практиковаться.


Ваш первый пример вряд ли вреден. Vim на самом деле довольно вменяемый при редактировании бинарных файлов. И в худшем случае вы можете просто закрыть окно. Второй пример с «да» раздражает и потребляет значительную часть пользовательского процессора, но система останется отзывчивой, и вы можете легко убить окно родительского терминала.
nneonneo

1
Я не согласен с «испортить ваш терминал до такой степени, что он будет недоступен до перезагрузки» - попробуйте reset, это должно очистить терминал, на котором был напечатан двоичный вывод. или просто
Josh

1
Круто, nw @JFA. На самом деле мне потребовалось несколько лет, чтобы освоить resetтрюк! Для получения дополнительной информации: unix.stackexchange.com/questions/79684
Джош

1
@ Джош, спасибо тебе за это, это очень помогло. Это действительно было много лет для меня: P
JFA

1
@Josh Тогда 'stty sane ^ M' и 'tput reset' также должны вас заинтересовать.
user2497

4

Я только новичок в bash, но вы могли бы немного установить True; сделать КОМАНДУ; сделанный; Большинство людей попробуют Ctrl + C, который остановит команду, а не внешний процесс (ctrl + Z, который затем необходимо убить). Я предполагаю, что если команда - это какая-то тяжелая операция, например умножение большого числа на собственную мощность, это может испортить ваши ресурсы. Но на самом деле современные ОС обычно защищены от такого беспорядка.


2
Он работает очень быстро, ничего не сломается. Вам просто нужно провести несколько интенсивных вычислений, чтобы ядро ​​maxprocs не расстраивало вас. попробуйwhile true do cat /dev/zero > /dev/null & done
user2497

Благодарю. Я ожидал, что обработка больших чисел заставит компьютер работать медленнее, иногда это происходит с очень простыми программами java / python, которые я использовал для машинного обучения.
Андо Джурай

1
Бит от нуля до ноля - это операция с большими числами, по крайней мере в I / O. Я использую один из них на каждое ядро ​​ЦП для проведения тепловых испытаний.
user2497

1
И ^C также убьет цикл while, но он просто повторяется слишком быстро, чтобы прерывание было перехвачено. Удерживание ^Cможет вырваться из петли. Закрытие терминала тоже будет :)
Джош

2
@Josh Легче поймать INT, если после задачи, интенсивно использующей процессор, есть небольшая пауза, например, сон 0.1.
user2497

3

Конечно, вы все еще можете вызвать сбой системы с помощью команд, введенных с помощью терминала.

С годами становится все труднее, вероятно, из-за всевозможных ограничений и применяемых защитных мер, но, как утверждает закон Мерфи: «Ничто не может быть надежным для достаточно способного дурака».

«Вилочные бомбы» и все, что rm -rfсвязано с детскими сценариями - это древние вещи, известные для UNIX. С Mac OS X вы можете получить больше удовольствия от использования его частей подсистемы GUI ( WindowServerчтобы упомянуть) или чего-то вроде брандмауэра OpenBSD, известного PFкак инженеры Apple, которые не смогли обновить с момента своего 2008 года. PFработает в ядре, поэтому, когда он улавливает причуду, Apple сообщает вам « вы перезагрузили компьютер из-за паники» или что-то в этом роде.

Хуже всего то, что вы никогда не сможете понять, почему это панически - почему Apple не предоставляет никаких значимых следов стека; Вы можете иметь только шестнадцатеричные числа адресов возврата стекового фрейма.


Хороший ответ и отличные очки. Я хотел бы добавить в ваш список прекрасных способов заставить OS X паниковать на танцполе моего личного фаворита, но без явных терминов, чтобы избежать глупостей детского сценария. Я выгружаю расширение ядра, относящееся к NFC. Работает каждый раз, мгновенно. Можно легко превратить это в DOS, запланировав это на делимое количество, например, 5 минут. Следовательно, он загрузится, а затем погрузится в лебедь. Это требует переустановки ОС, учитывая, что большинство администраторов пропустят это ...
Фрэнсис из ResponseBase

3

Это немного двусмысленно, что вы подразумеваете под "сбой" вашего компьютера ... и нет однозначного правильного ответа на это, хотя в других ответах есть несколько полезных примеров. Поскольку ваш вопрос более двусмысленный и общий, я хотел бы сосредоточиться на природе вопроса и дать более общий ответ.

Люди, которые не понимают Терминал, часто боятся его использовать, опасаясь, что они могут испортить свою команду и сломать компьютер.

Я думаю, что командная строка - обоюдоострый меч, и часто очень острый. Его самая сильная сторона - это также самая большая слабость для новых пользователей: программы CLI делают то, что вы говорите, не спрашивая, действительно ли это то, что вы имели в виду. Они часто не просят подтверждения, они не предоставляют ручную или интерактивную помощь, и их варианты являются короткими, часто краткими, иногда сбивающими с толку текстовыми строками. Обратите внимание, что они, как правило, очень хорошо документированы, нужно просто прочитать руководство (которое почти всегда man <command you are about to run>) и потратить время, чтобы понять, что будет делать командная строка, которую они собираются запустить.

Этот режим работы является мощным - это означает, что опытные пользователи CLI могут создавать длинные командные «конвейеры», которые выполняют сложные задачи с помощью одной команды. Это потому, что задача не спросит "Вы уверены?" на каждом шагу он делает то, что ему говорят. Но для пользователя, незнакомого с этим режимом и привыкшего к графическому интерфейсу, где онлайн-справка находится на расстоянии одного клика , это незнакомо и страшно.

Но есть ли на самом деле команды, которые сломают ваш компьютер?

Можете ли вы «разбить» свой компьютер с помощью CLI? Может быть. Безусловно, вы можете вызвать потерю данных, если неправильно используете деструктивную команду. Например, многие ответы здесь упоминают rm, команда, которая удаляет файлы. Очевидно, что с помощью этой команды вы можете потерять данные, это то, для чего команда была предназначена.

Как указывалось в других ответах, вы можете использовать командную строку, чтобы сделать вашу машину практически неработоспособной в течение определенного периода времени: вы можете завершить работу без подтверждения, заставить процесс использовать 100% доступных ресурсов без подтверждения, убить все ваши программы или уничтожить вашу файловую систему. Если вы действительно хотите, вы можете использовать CLI для создания расширения ядра, которое вызывает панику ядра (что наиболее близко к «краху», о котором я могу думать).

Командная строка (доступ через Терминал) является мощным инструментом. Часто решить проблему с помощью терминала быстрее, чем с графическим интерфейсом. Некоторые решения доступны только с использованием команд терминала. Тем не менее, ключом к CLI является понимание . Не выполняйте случайные команды, которые вы видите онлайн. Прочитайте справочные страницы и поймите, что делают команды. Если вы не уверены, спросите кого-нибудь или узнайте больше о команде перед ее выполнением.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.