Как иметь сценарий, обнаруживают, если эмулятор терминала работает на настольной сессии или нет?

Question 1

У меня есть скрипты, которые я запускаю, которые выписывают текстовый файл, затем открывают его в редакторе. Если бы я открываю окно эмулятора терминала на своей настольной сессии и запускаю скрипт, я хотел бы, чтобы редактор был графическим такой как gedit. Но, если бы я зарегистрирован через ConnectBot по моему телефону или подобный (никакая настольная сессия), я хотел бы, чтобы редактор был nano.

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

Сценарий может обнаружить, какая из этих ситуаций я нахожусь в и открываю корректного редактора?

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

Question 2

Можно использовать переменную среды $DISPLAY как инициировали в a if состояние. Обычно, когда эта переменная имеет значение, Вы можете запустить графические приложения.

Вот пример удара:

if [[ -z $DISPLAY ]]
then
    nano
else
    gedit
fi

Оператор -z возвратит true когда envvar $DISPLAY пусто, и Ваш сценарий будет работать nano, во всех других случаях это будет работать gedit.

Согласно этому комментарию @vurp0:

На большинстве современных рабочих столов Уэйленда (как рабочий стол по умолчанию в Fedora и Ubuntu), $DISPLAY все еще установлен из-за назад совместимости (через XWayland), но для более устойчивого сценария было бы хорошо протестировать на обоих $DISPLAY и $WAYLAND_DISPLAY быть уверенным.

Я предложил бы изменить проверяемое выражение следующим образом:

[[ -z ${DISPLAY}${WAYLAND_DISPLAY} ]]

Таким образом значения этих двух переменных будут связаны в общую строку, которая будет обработана оператором -z.

Ссылки:

Question 3

Question 4

Использование обычно виртуальных терминалов /dev/pts псевдотерминалы. Так, на основе вывода tty команда, мы можем создать простое case оператор для обработки вводного конкретного редактора:

case "$(tty)" in ; "/dev/pts"*) nano ;; "/dev/tty"*) gedit ;; ;esac

Или отформатированный более приятно:

case "$(tty)" in
    "/dev/pts"*) gedit ;; 
    "/dev/tty"*) nano ;;
    *) echo "Not suitable tty" > /dev/stderr ;;
esac

По сравнению с использованием переменных среды это немного более надежно и полагает, что использует case оператор с tty управляйте немного более портативный. То, что, вероятно, было бы лучшим, должно объединить обоих, с дополнительным тестированием, такой как "/dev/tty"*) [ -n "$DISPLAY" ] && gedit ;;

Question 5

Это - то, что я использовал:

# $TERM variable may be missing when called via desktop shortcut
CurrentTERM=$(env | grep TERM)
if [[ $CurrentTERM == "" ]] ; then
    notify-send --urgency=critical "$0 cannot be run from GUI without TERM environment variable."
    exit 1
fi

Причиной этого кода был этот вопрос: Настольный ярлык на катастрофические отказы сценария Bash и записи

Можно изменить его для сходства с этим:

# $TERM variable may be missing when called via desktop shortcut
CurrentTERM=$(env | grep TERM)
if [[ $CurrentTERM == "" ]] ; then
    nano ...
else
    gedit ...
fi

pa4080 · Accepted Answer · 23 November 2019 в 04:20