Я щодня використовую екран для потреб своїх терміналів, і я цілком задоволений цим. В останній час , хоча, я зробив деякі оновлення мої файли конфігурації Баш , і я помітив , що я встановлював різні PATHелементи ( PATH, MANPATH, INFOPATHі т.д.) в 2 -х місцях. Я змінив файли такими, якими вони повинні бути, і тепер усі мої змінні середовища встановлюються один раз .bash_profile. У цьому криється моя проблема.

Мабуть, причиною того, що я встановлював їх у двох місцях, було через екран. на екрані, як видається, виконується тільки він, .bashrcі не здається, що він міг наслідувати мої PATHабо будь-які інші змінні середовища з моєї оригінальної оболонки bash. Оскільки він лише виконується, .bashrcі тепер я встановлюю лише свої змінні .bash_profile, я отримую неповне PATH.

Отже, моє питання полягає в тому, як повернути мої змінні середовища на екран без дублювання. Читання Bashдокументів немовби вказує на те, що це може бути така форма оболонки, якою використовується екран для входу, тобто інтерактивна оболонка без входу, але я не міг зрозуміти, як змусити екран використовувати певний тип оболонки, лише оболонки для використання через -s /bin/bash.

Ви можете ознайомитися з моїми конфігураційними файлами на моїй сторінці GitHub . Це фіксація, яка зламала екран .

EDIT: Я використовую, Screen version 4.00.03 (FAU) 23-Oct-06і я схильний викликати цеscreen -h 50000

EDIT: Зараз я міг перевірити це на Cygwin ( CYGWIN_NT-5.1 1.7.1(0.218/5/3) i686, Screen version 4.00.03 (FAU) 23-Oct-06), і це проявляє іншу поведінку, ніж на моєму Mac.

Конкретна поведінка, яку я зараз виявив, полягає в тому, що в Cygwin зміни, які я вношу PATHв .bash_profile, дублюються при вході на екран, а потім послідовні створення вікон екрана не дублюють шлях, а повторюють .bash_profile.

Для ілюстрації поведінки, про яку я говорю:

Вихід із свіжого терміналу:

...

PATH: /home/tvishe01/bin/emacs/bin:/home/tvishe01/bin:/usr/local/bin:/usr/bin:/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Program Files/ATI Technologies/ATI.ACE/Core-Static:/groovy-1.6.1/bin:/usr/lib/lapack

MANPATH: /home/tvishe01/share/man:/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man

Aliases:
alias ..='cd ..'
alias ...='cd ../..'

...

[~]$

Виведення з першого виклику екрана:

[~]$ screen -h 50000 -s -/bin/bash

...

PATH: /home/tvishe01/bin/emacs/bin:/home/tvishe01/bin:/usr/local/bin:/usr/bin:/bin:/home/tvishe01/bin/emacs/bin:/home/tvishe01/bin:/usr/local/bin:/usr/bin:/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Program Files/ATI Technologies/ATI.ACE/Core-Static:/groovy-1.6.1/bin:/usr/lib/lapack

MANPATH: /home/tvishe01/share/man:/usr/local/man:/usr/share/man:/usr/man:/home/tvishe01/share/man:/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man:/usr/ssl/man

Aliases:
alias ..='cd ..'
alias ...='cd ../..'

...

[~]$

Наступні дзвінки на C-a c:

...

PATH: /home/tvishe01/bin/emacs/bin:/home/tvishe01/bin:/usr/local/bin:/usr/bin:/bin:/home/tvishe01/bin/emacs/bin:/home/tvishe01/bin:/usr/local/bin:/usr/bin:/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Program Files/ATI Technologies/ATI.ACE/Core-Static:/groovy-1.6.1/bin:/usr/lib/lapack

MANPATH: /home/tvishe01/share/man:/usr/local/man:/usr/share/man:/usr/man:/home/tvishe01/share/man:/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man:/usr/ssl/man

Aliases:
alias ..='cd ..'
alias ...='cd ../..'

...

[~]$

Ти можеш бачити

екран і змінні середовища

За замовчуванням екран проходить уздовж своїх оболонок (та інших процесів) будь-які змінні середовища, які він мав при запуску сеансу (тобто повторне з'єднання не змінює, які змінні середовища надаються новим оболонкам). Але оскільки файли конфігурації екрана та оболонок зазвичай змінюють змінні середовища, існує багато місць, де можна ввести несподівані зміни. Існує кілька змінних, таких як TERM , які на екрані майже завжди змінюються, але вони, як правило, потрібні для функцій, які надає екран .

Скажімо, що ні конфігурація вашої оболонки, ні конфігурація екрана не змінять змінну з назвою FOOBAR (досить вірогідно, загалом ). Якщо ви почнете сеанс з FOOBAR=foo screen, тоді всі оболонки, створені на цьому сеансі, матимуть змінну середовища з назвою FOOBAR зі значенням foo.

Все стає складнішим для змінних, які можуть змінити або екран, або оболонку.

Відсутні параметри при використанні екрана

Оболонки для входу

Якщо ви виявите, що в оболонках, запущених екраном , відсутні деякі налаштування , це може бути через те, що ваша оболонка налаштована лише для оновлення цих параметрів для оболонок "входу". Більшість снарядів розуміють спеціальну конвенцію (в C: **argv == '-') , що екран може бути налаштований для використання.

За документами на екрані :

команда оболонки

Встановіть команду, яка використовуватиметься для створення нової оболонки. Це переосмислює значення змінної середовища $ SHELL. Це корисно, якщо ви хочете запустити tty-посилювач, який очікує виконання програми, визначеної у $ SHELL. Якщо команда починається з символу '-', оболонка буде запущена як оболонка для входу.

Для того, щоб мати екран початок оболонки , як «входу» оболонок, початок екрану з screen -s -/bin/bash, або додати цей рядок в .screenrc:

shell -/bin/bash

Налаштуйте шлях до будь-якої оболонки, яку ви використовуєте.

Конфігурація екрана

Відсутня або скидання змінних середовища також може бути з - за setenvі unsetenvкоманди в вікно файлу конфігурації. Вам потрібно буде перевірити обидва .screenrc у домашньому каталозі та в якому файлі ваша компіляція екрана використовується як "system screenrc" (ви можете спробувати команду, як strings "$(which screen)" | fgrep -i screenrcзнайти ім'я шляху, яке було налаштовано під час компіляції - зазвичай / etc / screenrc для встановленого системою екрана ; додаткові установки, ймовірно, використовуватимуть інше ім'я шляху). Ви можете використовувати SCREENRC=/dev/null SYSSCREENRC=/dev/null screenдля тимчасового уникнення цих параметрів файлів налаштувань, але є варіант часу компіляції, який перешкоджає ефективному використанню SYSSCREENRC (імовірно, щоб системні адміністратори могли змусити якийсь біт початкової конфігурації).

Дублювання налаштувань під час використання екрана

Досить часто додавати елементи до змінної середовища, наприклад PATH, у файл (и) конфігурації оболонки, щоб оновлене значення було доступне для звичайних сеансів оболонки (наприклад, xterm або інші вікна терміналів, сеанси консолі тощо). Якщо такі елементи додаються в конфігурації оболонки на оболонку (або, якщо ви використовуєте -/path/to/shellналаштування, описане вище, у конфігурації оболонок за входом), тоді оболонка, запущена екраном , швидше за все матиме декілька копій доданих елементів.

Одна з стратегій, щоб цього уникнути, - це включити всі доповнення до змінних, таких як PATH, у конфігурацію для входу в оболонку і уникати використання параметрів -/path/to/shellоболонки з екраном .

Інша стратегія - лише умовно додавати нові елементи до змінної. Залежно від оболонки, код для цього може бути дещо складним, але він, як правило, може бути інкапсульований у функції оболонки для зручного використання.

Ще одна стратегія - завжди починати з фіксованого значення у ваших файлах конфігурації. Іноді це може спричинити проблеми під час переміщення конфігураційних файлів із системи в систему, коли значення за замовчуванням можуть істотно відрізнятися.

Діагностика

Якщо ви не можете безпосередньо визначити, де відбувається певна модифікація, ви можете спробувати наступне, щоб відстежити, де відбувається зміна.

Перевірте поточне значення у початковій оболонці:

echo "$PATH"

Перевірте, як сама оболонка змінює значення, коли створюється під-оболонка:

/bin/bash -c 'echo "$PATH"'

Перевірте, як оболонка змінює значення під час створення підкошти "входу":

perl -e '$s=shift;exec {$s} "-$s", @ARGV or die "unable to start shell"' /bin/bash
echo "$PATH"
exit

Перевірте, як екран змінює значення:

printf '#!/bin/sh\nl=/tmp/echo-var.log;rm -f "$l"; echo $PATH >"$l"' >/tmp/echo-var &&
chmod a+x /tmp/echo-var &&
screen -s /tmp/echo-var &&
cat /tmp/echo-var.log

Востаннє, коли я бачив подібну проблему, я вирішив її, використовуючи screen -lпід час запуску екрана.

Ви можете скористатися -lопцією під час виклику screen(увімкніть режим входу ; також керується командами defloginта loginкомандами .screenrc), щоб встановити, чи повинен екран заносити вікно за замовчуванням (додавання / видалення запису / etc / utmp).

Режим входу ввімкнено за замовчуванням, але це можна змінити під час компіляції. Якщо екран не компільований з підтримкою utmp, ці команди недоступні.

Мені, здається, не потрібен -lрежим на екрані за замовчуванням Дебіана Ленні (v4.0.3); це, здається, увімкнено за замовчуванням. Мої ~/.profileі ~/.bashrcчитаємо правильно. Як ви звертаєтесь screen? Яку версію ви використовуєте?

Проблема полягає у запущеній поведінці на Leopard. Перегляньте цей звіт про помилки MacPorts на екрані на Leopard, щоб дізнатися, чому його не виправити, якщо ви не зможете якось підтримати запуск Snow Leopard.

https://trac.macports.org/ticket/18235#comment:26

Немає нічого поганого в пошуку вашого .bashrc зсередини .bash_profile. Якщо ви використовуєте свій апарат лише локально, ваш .bash_profile в більшості випадків буде отриманий лише тоді, коли ви виконаєте свій початковий логін (очевидно, в інший момент він стає доступним).

Я впорядковую свої файли так, що якщо я хочу щось зробити лише під час входу, я вкладаю інформацію в .bash_profile, а для всього іншого я вкладаю їх у .bashrc. PATH - це одне, що я поміщаю у свій .bashrc, і я вивожу .bashrc у своєму .bash_profile.

Всякий раз , коли у мене є якась - то проблема , як я створити файл $HOME/.debugі всі файли джерел / виконується під час входу / оболонки виклику (наприклад ~/.bashrc, ~/.bash_profile, ~/.profile, /etc/bashrcі т.д.) У мене є в першому рядку

test -f $HOME/.debug && echo $HOME/.bashrc 1>&2

або подібне. Для конкретної налагодження ви також можете додавати такі речі

test -f $HOME/.debug && echo PATH now equals $PATH 1>&2

Таким чином ви можете бути на 100% абсолютно впевнені, які файли використовуються чи ні.

Перенаправлення на stderr важливо, ви не хочете, щоб щось псувало stdout у багатьох ситуаціях.

Ви можете залишатися з .profile, оскільки система не торкається bashrc (як графічна сесія). Тепер у вас просто два різних набори середовища - один з .profile, інший для bash від .bashrc.