PS1 установлен на -bash-3.2 $ после использования chmod

Question

Я следовал инструкциям по установке WSJT-X (радиопрограмма), и он заставил меня переместить файл с именем sysctl.conf на рабочий стол и выполнить следующие команды терминала:

  sudo cp $HOME/Desktop/sysctl.conf /etc/
  sudo chmod 664 /etc/sysctl.conf
  sudo chown  root:wheel  /etc/sysctl.conf

После выполнения этих команд мой дисплей терминала изменился так:

Тогда как раньше мое имя было до знака доллара. Кроме того, моя дата и время теперь отображаются неправильно (установите 8 часов в будущем). Может кто-нибудь, пожалуйста, помогите мне узнать, что я сделал не так и как я могу это исправить?

Если это поможет, я думаю, что я случайно вставил пробел во второй команде, чтобы он стал

sudo chmod 664 /etc/ sysctl.conf

Answer 1

_{(Примечание: я парень из Linux, и у меня нет опыта работы с macOS. Примите мой ответ с небольшим количеством соли).}

С помощью sudo chmod 664 /etc/ вы удалили бит выполнения из каталога, и фактически вы не можете получить доступ (читать, записывать) к элементам, находящимся внутри. Это включает в себя (среди прочих):

• /etc/profile , где определяется общий PS1 ,
• /etc/localtime , /etc/timezone или все, что использует macOS.

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

Если бы та же проблема возникла в моем Kubuntu (без шифрования или чего-то подобного), я бы загрузил live Linux Linux, смонтировал файловую систему и установил разрешения. Я не знаю, можете ли вы легко исправить macOS "извне", как это.

Этот (старый) вопрос касается аналогичной проблемы, когда sudo не работает из-за неправильных разрешений /etc/sudoers . Возможные решения из ответов:

Это может быть одним из редких случаев, когда запуск "Восстановить права доступа к диску" из Дисковой утилиты может быть оправдан.

Если это не сработает, следуйте […] предложению загрузки в однопользовательском режиме, чтобы исправить это

Это выглядит многообещающе:

Другой подход заключается в использовании Automator.app .

Создайте новый рабочий процесс, который содержит что-то вроде следующего:

do shell script "chmod 0440 /etc/sudoers" with administrator privileges

Когда вы запустите его, он запросит ваш пароль и (предположим, что вы администратор) исправит это.

Это также работает, если вы испортили разрешения для родительского каталога (например, создание / что-то отличное от 755).

Имейте в виду, что вам нужно использовать chmod 755 /etc , поэтому не вставляйте этот код вслепую. Ваш случай попадает под "испорченные разрешения на родительский каталог".

Answer 2

У вас должно быть разрешение +x для каталога («execute /traverse»), чтобы получить доступ к любому из объектов внутри, независимо от наличия прав на чтение этих объектов напрямую.

Ваша команда chmod 664 /etc удалила это, установив права доступа u=rw,g=rw,o=r (это то, к чему декодируется восьмеричное число), так что теперь 1) оболочка не может получить доступ к /etc /profile и /etc /bashrc где сохраняется общесистемная настройка PS1; 2) система не может получить доступ к /etc /localtime или его эквиваленту macOS, где хранятся общесистемные параметры часового пояса.

Используйте chmod 775 или chmod a+x в каталоге, чтобы восстановить его. (7 и 5 декодируют до = rwx и = rx.)

(На самом деле я не уверен, что /etc должен быть доступен для записи в группе даже в macOS, так что вы могли бы также захотеть использовать chmod 755 - или дополнительный chmod g-w .)