Можем ли мы переключиться на SysV в дистрибутиве, который по умолчанию использует systemd? [closed]
ls вывод обычно не может быть надежно постобработан.
Если вы можете гарантировать, что имена файлов не содержат символов новой строки, вы можете сделать:
ls -AlLR ./| grep -E '^-(..[[:lower:]]){3}'
То есть вывести строки, которые начинаются с - (только для обычных файлов) и для которых третий символ в каждая группа из 3 символов в поле разрешения представляет собой строчную букву (на практике это обычно либо x , s , l , либо t . Некоторые системы могут иметь расширения, но они сделают это строчной буквой, если файл исполняемый).
Обратите внимание, что он будет печатать только имя файла, а не его полный путь.
С помощью zsh вы также можете:
printf '%s\n' **/*(D-.f+111)
Или:
printf '%s\n' **/*(D-.f:a+x:)
Изнутри bash :
zsh -c 'printf "%s\n" **/*(D-.f+111)'
Я полагаю, вы используете -L в подходе find , потому что для символических ссылок вы хотите проверить цель символической ссылки. Это цель флага - выше.
Однако обратите внимание, что еще один побочный эффект -L find заключается в том, что он спускается в символические ссылки на каталоги. То же самое произойдет с ls -LR , а не с этим решением zsh выше.Если вы действительно хотите перейти в символические ссылки на каталоги, замените ** на *** , если вы хотите избежать перехода в символические ссылки на каталоги с помощью find , с GNU find (как в Ubuntu) вы можете сделать:
find -L . \( ! -xtype l -o -prune \) -type f -perm -111
В любом случае, все они не будут принимать во внимание файлы, разрешения которых сами по себе сделали бы их исполняемыми для всех, но сидят в каталогах, которые не доступны для поиска всем. Это также может дать неверные результаты, если используются списки контроля доступа или другие меры безопасности.
Чтобы также учитывать возможность поиска компонентов пути, вы могли бы сделать:
find -L . \( ! -xtype l -perm -111 -o -prune \) -perm -111
(при условии, что все компоненты пути, ведущие к самому текущему рабочему каталогу, также доступны для поиска по всему миру)
Поскольку systemd появился позже, у него есть механизм для запуска старых сценариев инициализации SysV для прямой совместимости.
Пакеты, разработанные для системы на основе systemd, могут только поставлять сценарий «службы» на основе systemd, а не устаревший сценарий «init.d».
Я не думаю, что у SysV есть способ читать служебные файлы systemd. Поэтому некоторые службы могут не запускаться должным образом при использовании старой системы инициализации.
Не обязательно.
Согласно http://without-systemd.org/ Debian Джесси теряет polkit. Нецелесообразно запускать рабочий стол без механизма повышения привилегий, например. для установки обновлений. (Как следует из названия PolicyKit, идея состоит в том, чтобы разрешить разные политики - например, для разных групп пользователей или для разных дистрибутивов Linux).
Я не говорю, что Debian был неправ, оставив его для другого выпуска, но проблема, когда вы используете подход смешивания и сопоставления, заключается в том, что трудно понять, что на самом деле должно работать.
Я не уверен, что это считается явным отказом от его поддержки, но это звучит как «вам лучше уже знать, что вы делаете».
[Внимание]
Имейте в виду, что некоторые пакеты могут иметь ухудшенное поведение или могут не иметь функций при инициализации не по умолчанию система.
Серверные системы гораздо реже сталкиваются с проблемами в этом контексте.