То, когда делает оболочку, выполняется во время процесса запуска Linux
Использовать xargs:
$ command ls /proc | grep -v "^[0-9].*" | xargs
command часть необходима потому что если Ваш ls искажается к ls --color например, это добавляет непечатаемые escape-последовательности к своему выводу это grep так или иначе перерывает и приводит к нежелательным результатам.
Другие опции
Если Вы не возражаете против Вашего PWD изменение:
$ cd /proc && echo [^0-9]*
Если Вы не хотите изменять Ваш PWD:
$ pushd . &>/dev/null && cd /proc && echo [^0-9]* && popd &>/dev/null
Или:
$ echo /proc/[^0-9]* | sed 's!/proc/!!g'
Последовательность загрузки linux/unix имеет много этапов, и на этом сайте есть много ссылок и ответов, которые объясняют детали. Но вкратце:
В конечном итоге ядро загружается с драйверами, чтобы можно было использовать диск и устройства, затем запускается процесс с pid (идентификатором процесса), равным 1.
Традиционно эта программа называлась init, но сегодня есть несколько более новых программ (systemd или upstart). Какая из них используется, зависит от вашего дистрибутива и версии.
Запуск - это многоуровневый процесс.
Существует концепция эскалации уровней запуска (1,2,3,4,5,6 ...), и программа запуска будет переключаться между этими уровнями автоматически или поэтапно (чтобы пользователь мог получить контроль).
- начальный этап (однопользовательский режим),
- многопользовательский режим,
- многопользовательский с сетевым взаимодействием
- режим GUI ...
- .. 6., ...
Эти уровни запуска также не застыли в камне, они зависят от дистрибутива и используемой программы запуска (init, systemd, ...) и конвенции.
Уровни также зависят от того, как была разработана схема поэтапного запуска/выключения. (Вспомните, linux используется в маршрутизаторах, телефонах android, серверах и настольных компьютерах с разными требованиями).
Для перехода с одного уровня запуска на другой запускаются или останавливаются различные другие программы (службы), такие как bind (для DNS), сети, маршрутизация, веб-серверы, ... и bash может быть использован для запуска определенного скрипта, который запускает или останавливает службу.
В конце концов, вам нужно войти в систему, либо в консоль, либо в графический интерфейс, и вам может быть предложено ввести имя пользователя и пароль.
Давайте пойдем простым путем и скажем, что вы находитесь на неграфической консоли, и программа login просит вас пройти аутентификацию. Когда вы пройдете, программа прочитает, какая оболочка настроена для введенного имени пользователя из /etc/passwd и запустит ее, с вводом и выводом на вашу консоль, после чего вы получите приглашение и сможете начать работу. Итак, в этом сценарии,
init запускается -> login, который запускается -> bash
Таким образом, каждый процесс является дочерним по отношению к первому процессу (точнее было бы сказать, что каждый процесс имеет pid 1 в качестве предка). В приведенном выше примере, login будет exec shell, заменяя процесс login на bash, id процесса не меняется. Когда вы смотрите ps, кажется, что bash был запущен init, потому что его родительский pid равен 1, но произошла цепочка событий.
На самом деле ничто не мешает pid 1 просто запустить bash на консоли (если pid 1 может понять, что такое консоль в этот момент), и это связано с тем, как разработана последовательность запуска. (Мне пришлось сделать это однажды, но это не является нормальной практикой).
Оболочка выполняется во время загрузки только при вызове скриптов оболочки. Традиционная система init построена на основе скриптов оболочки (каждый сервис/демон запускается из скрипта оболочки). Большинство служб запускается, когда система переходит в многопользовательский режим. Некоторые вещи могут запускаться и до этого (монтирование файловой системы может включать в себя вызов скриптов). На linux, initsrcipts выполняются с помощью
#!/usr/bin/env bash
cd /2/screenshots/
x=$(date +"%y%m%d%H%M%S")
screencapture -i -o $x.png
sips -s format jpeg -s formatOptions 60 $x.png -o $x.jpg
rm $x.png
, который начинает заменять Однако, systemd загружается без запущенных интерпретаторов оболочки, хотя вы всегда можете иметь службу, которая сама по себе является скриптом оболочки.
Конечно, пользовательская оболочка по умолчанию запускается при входе в систему, но этопослепроцесса загрузки. Если вы загружаетесь в диспетчере дисплеев (большинство пользовательских дистрибутивов делают это по умолчанию), оболочка командной строки может никогда не быть запущена вообще. Они даже худят терминальный эмулятор, так что нужно покопаться в уровнях меню, чтобы добраться до него.С помощью небольшого взлома можно записать в журнал все bash экземпляры, которые запускаются. Будьте осторожны, это опасно, вы можете взломать систему. Временно скопируйте свой bash из/bin/в какое-нибудь другое место (/usr/local/bin), потому что он приходит позже в $PATH). Напишите скрипт оболочки вроде этого:
замените /bin/bash на этот скрипт. Внутренне он вызывает real bash, так что это не бесконечный цикл. Он регистрирует дату и PID процесса (не используйте логгер, система регистрации, возможно, еще не запущена). Вы также увидите, какие скрипты выполняются.
Повторяю: не делайте этого до тех пор, пока не полностью не поймете все шаги. И не забудьте откатить все изменения после того, как закончите.
В Unix оболочка - это просто другая программа. Вокруг даже есть множество оболочек, удовлетворяющих специфическим извращениям различных пользователей в области интерфейса командной строки. POSIX предписывает, что конкретная оболочка (по сути, урезанная оболочка Борна) должна быть доступна.
Короткий ответ: Оболочка запускается, когда это необходимо, и не раньше.
Длинный ответ:
Самое очевидное время запуска оболочки - это когда пользователь входит в систему. Программа tty, обрабатывающая сеанс пользователя, запускает оболочку.
Другая возможность - когда она нужна cronjob, если cronjob использует скрипт, а не двоичный файл.
И еще есть возможность, что для запуска некоторых служб оболочку нужно вызвать, чтобы запустить скрипт.
Первая и основная задача ядра при загрузке - найти и вызвать init - пользовательское пространство. Ваш initramfs вряд ли будет чем-то большим, чем образ диска Linux, содержащий этот 'init' и столько файлов, сколько необходимо для упаковки в этот образ для init , чтобы найти и смонтировать ваш настоящий корневая файловая система. По сути, это не жесткие правила, но они являются стандартом де-факто.
Настоящая проблема с ответом на этот вопрос заключается в том, что хотя init очень часто является оболочкой, а несколько файлов, сопровождающих ее в initramfs, представляют собой просто сценарии оболочки и несколько модулей ядра, необходимых для монтирования вашего корневого устройства, это, конечно, не должно быть. Ядру все равно - оно просто хочет init .
Так что ответ на этот вопрос, я думаю, будет сразу после того, как вы настроите его для вызова.
ПОДРОБНЕЕ ...
Вы можете проверить это довольно легко - включите выбранную оболочку в образ initramfs и добавьте параметр:
"init=/path/to/shell"
в командную строку ядра загрузчика. Пока зависимости вашей оболочки соблюдены, ваша следующая загрузка должна предоставить вам интерактивную подсказку в раннем пользовательском пространстве.
Вероятно, даже не требуется добавлять оболочку, поскольку существует довольно высокая вероятность того, что ваш init уже является сеансом busybox со сценарием и
"init=/bin/sh"
подойдет также - хотя я ожидаю, что " точно так же "часть спорна. В любом случае, если вы когда-либо сталкивались с одним из этих « запроса аварийного восстановления », это, вероятно, было просто / bin / sh в initramfs , если только вы используете grub , и ваше ядро не загрузилось полностью, и в этом случае это определенно не так.
Стефан ниже комментирует разницу между init и init .Безусловно верно, что как только вызывается switchroot , следующая вызываемая программа с гораздо меньшей вероятностью будет оболочкой, чем когда ядро распаковало initramfs (что происходит независимо от того, предоставите ли вы один или нет, кстати) и называется init . И определенно сообщение, которое он прокомментировал, содержало гораздо меньше информации по этому поводу, чем это редактирование, но в этот момент любой вызываемый init является второй строкой - это просто пользовательское пространство , вызывающее пользовательское пространство .
Это важно в том, что любая передача управления предоставляется добровольно, обычно в сценарии оболочки, и не является необходимостью для работы, как это было при передаче обслуживания из пространства ядра в пользовательского пространства . Это может проявляться по-разному - например, ваш вариант вообще никогда не вызывать switchroot и запускать операционную систему из initramfs , или systemd , чтобы убить udev в раннем пользовательском пространстве , так что он может запустить новый процесс udev в качестве своего дочернего процесса - но я надеюсь, что теперь я немного неуверен в том, что init ] вызывается только один раз, и любая программа с именем init , вызываемая позже, несет факел init только после того, как начальный процесс передает его.
Другой ответ здесь комментирует, что init является традиционным , но, вероятно, сегодня это будет что-то другое .Я не уверен, что следую, но, насколько мне известно, init был до и до сих пор остается начальным процессом пользовательского пространства , вызываемым ядром при загрузке, как показано в init = параметр ядра, упомянутый выше, и чаще всего init является оболочкой.
Подводя итог, вероятно, лучше всего думать о init как о имени программы, а вместо этого как имя параметра , который определяет исполняемую программу. которому ядро передает первоначальный контроль над пользовательским пространством в целом.
Если у вас установлен pstree, вы можете сделать:
pstree | less
и использовать / для поиска программы, которая вас интересует (bash) Вы можете затем увидеть, каковы родительские и дочерние процессы для конкретных задач (выдержка):
|-tmux-+-bash---python2.7---2*[{python2.7}]
| `-sh---x2vnc---x2vnc