Lupo_Alberto Сообщения

Lupo_Alberto	# 2 года, 1 месяц назад
Темы: 10 Сообщения: 110 Участник с: 08 сентября 2013	Используйте bindcode вместо bindsym, тогда привязка клавиш не будет зависеть от выбранного языка.

Lupo_Alberto	# 3 года, 8 месяцев назад (отредактировано 3 года, 8 месяцев назад)
Темы: 10 Сообщения: 110 Участник с: 08 сентября 2013	P.S. Хотя найти команду, позволяющую просмотреть порядок присваивания переменных хотелось бы.

Lupo_Alberto	# 3 года, 8 месяцев назад
Темы: 10 Сообщения: 110 Участник с: 08 сентября 2013	akorop Конкретно $TERM ни в каком файле не присваивается, эту переменную создаёт сама программа терминала, и видят её значение программы, вызванные из этого терминала. Поучительно ввести echo $TERM в разных терминалах и в голой консоли. Спасибо. Так оно и оказалось.

Lupo_Alberto

# 3 года, 8 месяцев назад

Темы: 10

Сообщения: 110

Участник с: 08 сентября 2013

akorop
Конкретно $TERM ни в каком файле не присваивается, эту переменную создаёт сама программа терминала, и видят её значение программы, вызванные из этого терминала. Поучительно ввести echo $TERM в разных терминалах и в голой консоли.

Спасибо. Так оно и оказалось.

Lupo_Alberto	# 3 года, 8 месяцев назад
Темы: 10 Сообщения: 110 Участник с: 08 сентября 2013	red раз уже есть список мест где прописаны данные переменные то может просто погрепать на наличие нужной Что-то мне подсказывает, что и этот «велосипед» уже изобретён. Должна быть команда с подобным функционалом.

Lupo_Alberto	# 3 года, 8 месяцев назад
Темы: 10 Сообщения: 110 Участник с: 08 сентября 2013	Так, например, видно, где присваивается переменная EDITOR `% sudo grep "\<export\>" -r /etc \| grep -v ".#" \| grep "\<EDITOR\>" /etc/zsh/zshrc: export EDITOR=${EDITOR:-vim} /etc/zsh/zshrc: export EDITOR=${EDITOR:-vi}` ...но с TERM* ничего подобного не видно. Возможно, «виноват» Леннарт Пёттеринг, точнее systemd, который, может быть, занимается и настройками окружения.

Lupo_Alberto

# 3 года, 8 месяцев назад

Темы: 10

Сообщения: 110

Участник с: 08 сентября 2013

Так, например, видно, где присваивается переменная EDITOR


% sudo grep "\<export\>" -r /etc | grep -v ".*#" | grep "\<EDITOR\>"
/etc/zsh/zshrc:    export EDITOR=${EDITOR:-vim}
/etc/zsh/zshrc:    export EDITOR=${EDITOR:-vi}

...но с TERM ничего подобного не видно.
Возможно, «виноват» Леннарт Пёттеринг, точнее systemd, который, может быть, занимается и настройками окружения.

Lupo_Alberto	# 3 года, 8 месяцев назад
Темы: 10 Сообщения: 110 Участник с: 08 сентября 2013	red есть еще статья в нашей вики «Читал, много думал...» © Спасибо, но там я не нашёл ответа на свой вопрос.

Lupo_Alberto	# 3 года, 8 месяцев назад (отредактировано 3 года, 8 месяцев назад)
Темы: 10 Сообщения: 110 Участник с: 08 сентября 2013	Я, возможно, неправильно задал вопрос. Что такое системные, пользовательские, локальные переменные и как их назначить я знаю. Команда env выводит лишь список ИМЯ_ПЕРЕМЕННОЙ=значение. Меня интересует, в каком именно файле присваивается значение каждой из этих переменных. Так, к своему стыду, я не могу найти тот файл, где присваивается значение системной переменной TERM. Точнее, даже так: я знаю, где и как присвоить, но не могу найти, откуда оно берётся по-умолчанию. P.S. На вновь установленной системе, где происходит присваивание переменной TERM?

Lupo_Alberto

# 3 года, 8 месяцев назад (отредактировано 3 года, 8 месяцев назад)

Темы: 10

Сообщения: 110

Участник с: 08 сентября 2013

Я, возможно, неправильно задал вопрос.
Что такое системные, пользовательские, локальные переменные и как их назначить я знаю.
Команда env выводит лишь список ИМЯ_ПЕРЕМЕННОЙ=значение. Меня интересует, в каком именно файле присваивается значение каждой из этих переменных.
Так, к своему стыду, я не могу найти тот файл, где присваивается значение системной переменной TERM.
Точнее, даже так: я знаю, где и как присвоить, но не могу найти, откуда оно берётся по-умолчанию.
P.S. На вновь установленной системе, где происходит присваивание переменной TERM?

Lupo_Alberto	# 3 года, 8 месяцев назад (отредактировано 3 года, 8 месяцев назад)
Темы: 10 Сообщения: 110 Участник с: 08 сентября 2013	Есть ли возможность узнать, где именно определена та или иная переменная окружения?

Lupo_Alberto	# 3 года, 9 месяцев назад (отредактировано 3 года, 9 месяцев назад)
Темы: 10 Сообщения: 110 Участник с: 08 сентября 2013	Кто-нибудь может прокомментировать? asus-x201e% sudo find -L /usr -type l /usr/lib64/node_modules/node-gyp/node_modules/.bin/semver /usr/lib/node_modules/node-gyp/node_modules/.bin/semver asus-x201e% pacman -Qo /usr/lib64/node_modules/node-gyp/node_modules/.bin/semver /usr/lib/node_modules/node-gyp/node_modules/.bin/semver is owned by node-gyp 3.8.0-1 asus-x201e% sudo find -L /usr -type l -delete asus-x201e% sudo find -L /usr -type l asus-x201e% sudo pacman -S node-gyp warning: node-gyp-3.8.0-1 is up to date -- reinstalling resolving dependencies... looking for conflicting packages... Package (1) Old Version New Version Net Change community/node-gyp 3.8.0-1 3.8.0-1 0.00 MiB Total Installed Size: 6.83 MiB Net Upgrade Size: 0.00 MiB :: Proceed with installation? [Y/n] (1/1) checking keys in keyring [#########################] 100% (1/1) checking package integrity [#########################] 100% (1/1) loading package files [#########################] 100% (1/1) checking for file conflicts [#########################] 100% (1/1) checking available disk space [#########################] 100% warning: could not get file information for usr/lib/node_modules/node-gyp/node_modules/.bin/semver :: Processing package changes... (1/1) reinstalling node-gyp [#########################] 100% :: Running post-transaction hooks... (1/1) Arming ConditionNeedsUpdate... asus-x201e% sudo find -L /usr -type l /usr/lib64/node_modules/node-gyp/node_modules/.bin/semver /usr/lib/node_modules/node-gyp/node_modules/.bin/semver asus-x201e%

Lupo_Alberto

# 3 года, 9 месяцев назад (отредактировано 3 года, 9 месяцев назад)

Темы: 10

Сообщения: 110

Участник с: 08 сентября 2013

Кто-нибудь может прокомментировать?


asus-x201e% sudo find -L /usr -type l
/usr/lib64/node_modules/node-gyp/node_modules/.bin/semver
/usr/lib/node_modules/node-gyp/node_modules/.bin/semver

asus-x201e% pacman -Qo /usr/lib64/node_modules/node-gyp/node_modules/.bin/semver
/usr/lib/node_modules/node-gyp/node_modules/.bin/semver is owned by node-gyp 3.8.0-1

asus-x201e% sudo find -L /usr -type l -delete

asus-x201e% sudo find -L /usr -type l

asus-x201e% sudo pacman -S node-gyp
warning: node-gyp-3.8.0-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...

Package (1)         Old Version  New Version  Net Change

community/node-gyp  3.8.0-1      3.8.0-1        0.00 MiB

Total Installed Size:  6.83 MiB
Net Upgrade Size:      0.00 MiB

:: Proceed with installation? [Y/n]
(1/1) checking keys in keyring                     [#########################] 100%
(1/1) checking package integrity                   [#########################] 100%
(1/1) loading package files                        [#########################] 100%
(1/1) checking for file conflicts                  [#########################] 100%
(1/1) checking available disk space                [#########################] 100%
warning: could not get file information for usr/lib/node_modules/node-gyp/node_modules/.bin/semver
:: Processing package changes...
(1/1) reinstalling node-gyp                        [#########################] 100%
:: Running post-transaction hooks...
(1/1) Arming ConditionNeedsUpdate...

asus-x201e% sudo find -L /usr -type l
/usr/lib64/node_modules/node-gyp/node_modules/.bin/semver
/usr/lib/node_modules/node-gyp/node_modules/.bin/semver

asus-x201e%

Lupo_Alberto	# 3 года, 9 месяцев назад
Темы: 10 Сообщения: 110 Участник с: 08 сентября 2013	Можно чуть проще. Искать: `find -L /home/share -type l` Удалять: `find -L /home/share -type l -delete` ИМХО, удаление «сломанных» симлинков систему уже не сломает. Другое дело, нужно разбираться, почему они «сломаны».

Lupo_Alberto

# 3 года, 9 месяцев назад

Темы: 10

Сообщения: 110

Участник с: 08 сентября 2013

Можно чуть проще.
Искать:


find -L /home/share -type l

Удалять:


find -L /home/share -type l -delete

ИМХО, удаление «сломанных» симлинков систему уже не сломает. Другое дело, нужно разбираться, почему они «сломаны».