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

Я нашел эти методы на Форумах Ubuntu в потоке названными: Поток: Как я блокирую экран в XFCE?.

извлеченный из 2 из ответов в том потоке

Метод № 1 - Горячая клавиша

Откройте менеджер настроек> клавиатура> ярлыки, и Вы видите, что ярлык по умолчанию для блокировки экрана является ctrl-alt-del. Если Вы хотите изменить его, щелчок добавляют слева, вводят на название Вашего списка ярлыков, (расширьте окно, таким образом, Вы видите, все это) выбирают xflock4 ярлык справа и вводят новую ключевую комбинацию.

Метод № 2 - через командную строку

    $ xflock4

Метод № 3 - xscreenlock

Большую часть времени я использую xscreenlock на множестве дистрибутивов Linux. Это довольно повсеместно.

выборка с веб-сайта разработчиков

XScreenSaver является стандартным набором экранной заставки, поставленным в большинстве систем Linux и Unix, выполняющих Оконную систему X11. Я выпустил первую версию в 1992. Я портировал его к MacOS X в 2006, и к iOS в 2012.

В системах X11 XScreenSaver является двумя вещами: это - оба большое количество экранных заставок; и это - также платформа для очищения и блокировки экрана.

В системах MacOS эти экранные заставки работают с обычной платформой сохранения экрана MacOS (X11 не требуется).

На устройствах на iOS это - приложение, которое позволяет Вам выполнить каждый из демонстрационных режимов вручную.

снимок экрана основного диалогового окна

    ss of dialog

. Существует тонна снимков экрана различных экранных заставок, и Xscreensaver также обеспечивает экран, блокирующий также.

2
20.10.2014, 10:48
2 ответа

Согласно эта kernel.org страница о беспроводных драйверах ; да у вас есть правильный водитель! Будет ли более новая версия (чем то, что поставляет ваш дистрибутив) лучше или нет, будет зависеть от... У меня были более новые версии драйверов работают лучше, но у меня также были более новые версии работают хуже...

Таким образом, лучшим ответом на этот вопрос ИМО является другой вопрос: «Работает ли он нормально»?! Я предполагаю из вашей ссылки, что, возможно, нет? Но если ответ да, то ИМО зачем с этим связываться!?

Если вы хотите попробовать более новую версию, первое, что я бы сделал, это проверил вас. Например, я использую Debian, чтобы сначала проверить наличие обновленного пакета встроенного ПО в «backports,» а затем проверить «тестирование.» После этого я бы посмотрел на kernel.org (ссылка выше) и/или проверил бэкпорты.

AFAIK Серверные драйверы Intel еще не интегрированы в ядро. Я сомневаюсь, что они все еще будут поддерживать драйверы для вашей карты (так что вам понадобится kernel.org для последних...).

-121--230416-

«под ключ» Linux в настоящее время основан на Debian (v13.x основан на Debian Wheezy; предыдущая версия v12.x на основе Squeeze; до этого была основана на Ubuntu - v11.x на основе Lucid).

Я прочитал , что редактирование /etc/default/rcS и добавление:

ASYNCMOUNTNFS=no

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

-121--245510-

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

  • В том смысле, что bash script.sh и ksh script.sh могут вести себя по-разному, да. Обычно эта разница заключается в том, что один из них работает и дает ошибку, но есть ряд вариантов. Многие простые сценарии будут иметь одинаковое поведение на общих оболочках, но более сложные сценарии, вероятно, ударят по одному из многочисленных различий между языками, предоставляемыми различными оболочками.

  • Будет ли сценарий вести себя по-разному в зависимости от значения SHELL ? Только если сценарий либо вызывает $ SHELL сам, либо тестирует или иным образом использует его значение, прямо или косвенно. Обычные сценарии-оболочки, как правило, не будут, но они могут.

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


Я думаю, что в вашем сценарии использования запущен ./script.sh , который является сценарием sh , из интерактивной оболочки, который является ksh . Если это правильно, мы в последнем случае выше, и сценарий почти наверняка будет вести себя в том же пути, как если бы вы использовали любую другую оболочку самостоятельно. Система всегда запускает новый процесс /bin/sh и сообщает ему выполнить сценарий.

4
27.01.2020, 22:00

Нет, это не имеет значения. #! / USR / BIN / SH означает «использование / usr / bin / sh для интерпретации этого сценария, поэтому значение вашего $ Shell не имеет значения.

0
27.01.2020, 22:00

Теги

Похожие вопросы