GNU画面は10.5.8で私のPATHを継承しません
私は端末のニーズに合わせて日常的に画面を使用しており、非常に満足しています。しかし最近、bash構成ファイルをいくつか更新したところ、さまざまなPATH要素（PATH、MANPATH、INFOPATH、など）2か所で。ファイルを本来あるべき状態に変更したところ、すべての環境変数が_.bash_profile_に一度設定されました。ここに私の問題があります。
どうやら、2か所に設置したのは画面のせいでした。画面は_.bashrc_のみを実行しているように見え、notは元のbashシェルからPATHまたはその他の環境変数を正しく継承していないように見えます。 _.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で、.bash_profileのPATHに加えた変更が画面に入るときに複製され、画面ウィンドウを連続して作成してもパスが複製されず、再ソースされることです。 .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 ../..'
...
[~]$
_あなたが見ることができます
screenおよび環境変数
デフォルトでは、screenは、セッションの開始時に持っていた環境変数をシェル（および他のプロセス）に渡します（つまり、再接続しても、どの環境変数が与えられるかは変わりません）新しいシェル）。ただし、screenとシェルの構成ファイルはどちらも環境変数を変更するのが一般的であるため、予期しない変更が発生する可能性のある場所はたくさんあります。[〜＃〜] term [〜＃〜]のように、screenitという変数がいくつかあります。ほとんどの場合変更されますが、これらは通常、screenが提供する機能に必要です。
シェルの構成もscreenの構成も、[〜＃〜] foobar [〜＃という名前の変数を変更しないとしましょう。 〜]（かなり可能性が高い、全体として）。 _FOOBAR=foo screen_でセッションを開始すると、そのセッションで作成されたすべてのシェルには、[〜＃〜] foobar [〜＃〜]という名前の環境変数が含まれます。 /値はfooです。
screenまたはシェルが変更する可能性のある変数の場合はさらに複雑になります。
screenを使用するときに設定がありません
ログインシェル
screenで開始されたシェルで一部の設定が欠落している場合は、シェルが「ログイン」シェルのそれらの設定のみを更新するように構成されていることが原因である可能性があります。ほとんどのシェルは、screenを使用するように構成できる特別な規則（C：_**argv == '-'_）を理解しています。
シェルcommand
新しいシェルを作成するために使用するコマンドを設定します。これは、環境変数$ Shellの値をオーバーライドします。これは、$ Shellで指定されたプログラムの実行を期待しているttyエンハンサーを実行する場合に役立ちます。コマンドが「-」文字で始まる場合、シェルはログインシェルとして開始されます。
screen開始シェルを「ログイン」シェルとして使用するには、screenを_screen -s -/bin/bash_で開始するか、追加します。 _.screenrc_へのこの行：
_Shell -/bin/bash
_使用しているシェルへのパスを調整します。
screen構成
環境変数の欠落またはリセットは、screen構成ファイル内のsetenvおよびunsetenvコマンドが原因である可能性もあります。ホームディレクトリの.screenrcと、screenのコンパイルで使用されているファイルの両方を確認する必要があります。 'system screenrc'として（strings "$(which screen)" | fgrep -i screenrcのようなコマンドを試して、コンパイル時に構成されたパス名を見つけることができます。通常は/ etc/screenrcシステムの場合-インストール済みscreen;アドオンのインストールではおそらく他のパス名が使用されます）。 _SCREENRC=/dev/null SYSSCREENRC=/dev/null screen_を使用して、これらの設定ファイルを一時的に回避できますが、[〜＃〜] sysscreenrc [〜＃〜] /の効果的な使用を妨げるコンパイル時オプションがあります。（おそらく、システム管理者が初期構成を少し強制できるようにするため）。
screenを使用すると設定が重複する
シェルの構成ファイルの[〜＃〜] path [〜＃〜]のような環境変数に項目を追加して、値が更新されるようにすることはかなり一般的です。通常のシェルセッション（例：xtermまたは他のターミナルウィンドウ、コンソールセッションなど）で使用できます。このようなアイテムがシェルのシェルごとの構成で追加された場合（または、上記の_-/path/to/Shell_設定を使用している場合は、ログインごとのシェルの構成で）、シェルはで開始されます。/screenには、追加されたアイテムの複数のコピーがある可能性があります。
これを回避するための1つの戦略は、[〜＃〜] path [〜＃〜]などの変数へのすべての追加をシェルのログインごとの構成に入れ、使用を避けることです。 _-/path/to/Shell_シェル設定（screen）。
もう1つの戦略は、条件付きで新しい項目のみを変数に追加することです。シェルによっては、これを行うためのコードが少し複雑になる場合がありますが、通常は簡単に使用できるようにシェル関数にカプセル化できます。
さらに別の戦略は、構成ファイルの固定値から常に開始することです。これにより、デフォルト値が大幅に異なる可能性がある場合に、構成ファイルをシステム間で移動するときに問題が発生することがあります。
診断
特定の変更が発生している場所を直接特定できない場合は、次の方法を試して、変更が発生している場所を追跡できます。
初期シェルの現在の値を確認します。
_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
_screenが値をどのように変更するかを確認します。
_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を使用して解決しました。
screenを呼び出すときに-lオプションを使用できます（ ログインモード をオンにします。また、のdefloginおよびloginコマンドによって制御されます。 .screenrc）画面がデフォルトでウィンドウにログインするかどうかを設定します（/ etc/utmpエントリの追加/削除）。
ログインモードはデフォルトでオンになっていますが、コンパイル時に変更できます。画面がutmpサポートでコンパイルされていない場合、これらのコマンドは使用できません。
Debian Lennyのデフォルト画面（v4.0.3）では-lモードは必要ないようです。デフォルトでオンになっているようです。私の~/.profileと~/.bashrcは正しく読み取られています。 screenをどのように呼び出していますか？どのバージョンを使用していますか？
問題は、Leopardで起動された動作にあります。 Leopardの画面については、このMacPortsバグレポートを参照して、Snow Leopardの起動を何らかの方法でバックポートできない限り、修正されない理由を確認してください。
.bash_profile内から.bashrcを調達することに何の問題もありません。マシンをローカルでのみ使用している場合、ほとんどの場合、.bash_profileは、最初のログインを行ったときにのみソースされます（明らかに他の場合もあります）。
ログイン時にのみ何かを実行したい場合は、情報を.bash_profileに入れ、それ以外はすべて.bashrcに入れるようにファイルを整理します。 PATHは私が.bashrcに入れるものの1つであり、.bash_profileで.bashrcを調達します。
そのような問題が発生したときはいつでも、ファイルを作成します$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を台無しにするものは必要ありません。
システムは（グラフィックセッションのように）bashrcに触れないため、.profileを使用できます。これで、2つの異なる環境セットが作成されました。1つは.profileからのもので、もう1つは.bashrcからのbash用です。