UNIX/Linuxにおけるシェルの1つであるbashでは、root(管理者)が全ユーザー対象に行う為の共通環境設定とユーザーごとにホームディレクトリで有効にできる個別の環境設定があります。
UNIX/Linuxでは、ハードディスクなどの各種機器やメモリですらファイルとして表現され、UNIX/Linuxシステムにおけるファイルのほとんどはテキストファイルであり、これらの各種環境設定もテキストファイルに記述します。
root(管理者)が全ユーザー対象に行う為の共通環境設定は通常のファイルとして、ホームディレクトリにおけるこうした設定ファイル、システム管理ファイルは、-aオブション付きで指定しない限り、デフォルト(既定)の ls コマンドでは表示されないファイル名の先頭に[ . ]を付加した隠しファイルとなっているのが普通です。
尚、[useradd]コマンドでユーザーを追加(user情報としても必要なのでそれ以前に[groupadd]でグループを追加)する際に[/etc/skel]や[/usr/share/skel]ディレクトリが存在すれば、そのディレクトリ内の構成がそのままホームディレクトリに適用されるようになっています。
bashを含め多くのシェルはインタプリタスクリプトとしてだけでなく、ログインからログアウト(sh/Bourne Shellはexit)まで管理できる仕組みであり、環境設定についても同様です。
.bashrc
.bash_profile
.inputrc
.profile
.bash_login
.bash_logout
例えば、[/etc/skel]や[/usr/share/skel]というディレクトリがある場合、そこにあるファイルは新規登録されたユーザー用ホームディレクトリの基本構成ファイルとして自動的にコピーされます。
環境によりますが、そこには、-aオブション付きで指定しない限り、デフォルト(既定)の ls コマンドでは表示されないドット/ピリオドで始まるいくつかのファイルが含まれています。
skelはskeleton/スケルトンの略で日本語ではiMacなどのPCや腕時計がスケルトンPC、スケルトンの腕時計として一時期流行したこともあり、スケルトンと言えば「透けて見える」という意味の方が印象が強いかもしれませんが、この場合もそういう解釈も成り立たないわけでもありませんが、どちらかというと「骨子」や「骨組み」から転じて「最小限必要なもの」、「本質的(基本的)な部分」、「基本構成」という意味合いの方が強いでしょう。
/etc/profile(と/etc/bashrc)
~/.bash_profile(と~/.bashrc)
~/.bash_login
~/.profile
UNIX/Linuxのbashでは起動時に(それぞれ存在すれば)、この順に読み込まれます。
但し、bashでは~/.profileは、~/.bash_profileや~/.bash_loginが存在する場合には読み込まれません。
~/.bash_logout
ログアウト時には、[~/.bash_logout]が読み込まれます。
[/etc/profile](と/etc/bashrc)は全ユーザー共通の設定で以降[~/]とあるものはユーザー個々(ホームディレクトリ)の設定です。
$ head -3 .profile
$ head -3 .bashrc
$ head -3 .bash_profile
通常、[~/.bash_profile](~/.profile)はログイン起動時のみ、[~/.bashrc]はサブシェル起動時やX Window起動時に読み込まれます。
しかし、それでは往々にしてログインシェル用とサブシェルなどその他シェル用に同じ設定を二重に行う必要が出てきてしまいますので、これを回避する為にも、また、その利便性からも結果的にshell起動時に常に設定ファイルを読み込めるように[/etc/profile]は[~/.profile]、[/etc/bashrc]は[~/.bashrc]、[~/.bashrc]は[~/.bash_profile]を通じて、それぞれ存在すれば読み込まれるように書かれ、その用をなすようにファイル構成されるのが一般的です。
この例ではファイル冒頭3行に当該行があり、headコマンドで該当するif文の3行を表示しており、ソースコマンドにsh組み込みコマンドドット/ピリオド.とbash組み込みコマンドのsourceを使用していますが、何れもカレントシェルにファイルを読み込むという同じことをするコマンドで(あって、この場合のドット/ピリオド.についてはカレントディレクトリのサブディレクトリetcという意味ではないのでドットとパスの間にはスペースが必要で)す。
このようにすれば、[~/.bashrc]は、ログインシェルもサブシェルなどその他シェルでも必ず読み込まれるようになるということです。
$ cat .bashrc
$ head .bash_profile
ファイル別の設定内容や設定そのものも一律に厳密に決まっているわけではなく、必要性や好みに応じて設定し、例えば常に読み込まれる(ように構成した)[bashrc]には、umask値(ディレクトリやファイルの新規作成時のパーミッション)設定、プロンプト用のPS1やPS2、タイムゾーンTZや端末設定TERM、言語設定LANG、実行パスの追加があればPATHなどの各種環境変数の設定、関数、さらにコマンドなどのエイリアス設定等々を、その他を[bash_profile]に記述するのもよいでしょう。
$ head -3 .profile
尚、bashではなく、shを起動した場合には、bashは伝統的なshを真似た振る舞いをし、スタートアップファイルとして/etc/profileと~/.profileだけを読み込み、その後は、POSIXモードで動作するので/etc/bashrcや.bashrc含め他のファイルは読み込まれませんが、前述の相互にファイルを読み込む一連のファイル関係の中で.profileが読み込まれる際に.bash_profileを読み込めば、POSIXモードを無視することにはなるものの、.bash_profileや.bashrcを読み込むこともできなくはありません。
但し、スクリプトなど非対話型でshを起動した場合はいかなるスタートアップファイルも読み込まれません。
$ history
1 ls
2 pwd
...
500 history
$ echo $HISTSIZE
500
bashを利用すると[~/.bash_history]というログインユーザーのコマンド履歴ファイルが作成され(るように既定で環境変数HISTFILEに設定されてい)ます。
履歴は、コマンドラインでemacsモード、viモードのいずれを使用しているかにもよりますが、(viの場合コマンドモードで)コマンドラインのプロンプト上で矢印キー(やそれに当たるキー)の上矢印キーを押すごとに履歴を遡ることができます。
更に履歴の一覧は[history]コマンドで確認できますが、コマンドライン上で上矢印キーを押すと表示される履歴も、この[history]コマンドに表示される履歴であり、「ログインユーザーがログイン中にコマンドラインに入力している履歴そのもの」であり、[history]コマンドで確認すると履歴の最後に追加されるのは、まさに[history]で、その履歴数の上限は環境変数HISTSIZEで設定された値です。
$ !2
$ fc 3
$ fc sed
また、[ ! ]を付加するとこれらの[history]履歴の番号のコマンドを再利用することができます。
尚、fcコマンドに履歴番号やキーワードを引数として指定すると番号ではその履歴番号の履歴内容、キーワードではマッチする最も直近の履歴内容、引数なしの場合には直前の履歴内容が、普段利用している(自動的に起動した)テキストエディタ上に表示され、編集して閉じると、その編集されたコマンドが実行されます。
$ echo $HISTFILE
/home/xxx/.bash_history
$ echo $HISTFILESIZE
500
bashでは再ログインした際にも履歴を利用できるようにログアウト時に環境変数HISTFILEに設定されたファイルに環境変数HISTFILESIZEを上限とした履歴数までの間、履歴を追加し、上限を超えると古い順に削除、新たな履歴を追加します。
このことから一度ログアウトして再ログインした直後に[history]コマンドで得ることができる履歴一覧は、前回のログアウト時にHISTFILEに設定されたファイルに格納された履歴(前回[logout]していれば[logout])に続いて今、実行した[history]が追加されたものということになります。
HISTFILE / HISTSIZE / HISTFILESIZE
履歴に関する変数(これらの一部または全部は実際には環境変数ではなく[set]コマンドで確認できるシェル変数)には3つあります。
$ echo $HISTSIZE
500
$ echo $HISTFILESIZE
500
HISTSIZE/HISTFILESIZEともに既定の履歴数は最大500(OSによっては1000)です。
HISTSIZEとHISTFILESIZEの履歴数に異なる値を設定することもできますが、HISTSIZEだけを変更しようとしても再ログイン時にはHISTFILESIZEにも同じ履歴数が反映され、他方HISTFILESIZEの履歴数だけを変更する場合はこのようなことはありません。
また、ホームディレクトリでvi/vimエディタを起動すれば[.virc]/[.vimrc]が、emacsを起動すれば[.emacs.d]ディレクトリが、lessコマンドを使用した場合には、lesshst/less history file等の履歴ファイルが含まれることになるでしょう。
言語(文字コード)対応も個別に設定したい場合はホームディレクトリの各種設定ファイルで設定することができ、(バッティングする設定がある場合)こうした(後に読み込まれる)ユーザー個別の設定は(先に読み込まれる)共通設定を上書きします。
日本語などASCII文字以外の入力や表示が必要な場合もホームディレクトリの設定ファイルと環境変数、端末設定で対応することができます。
set convert-meta off
set input-meta on
set output-meta on
シェル(sh/bash)では、[~/.inputrc]にconvert-meta/input-meta/output-metaのon/offをそれぞれ設定します。
ちなみに、これらはbash組み込みコマンドbindにおけるキーバインディング(キー割り当て)値の設定で、オプションによっていくつか確認方法はありますが、bind -vとすると機能名とその設定値を確認することができます。
set meta-flag on
尚、meta-flagはonになっていると思いますが、なっていない場合には、先の設定に加えmeta-flagもonにします。
export LANG=ja_JP.sjis
また「環境変数LANG」に必要に応じて[ja_JP.sjis][ja_JP.ujis][ja_JP.eucJP][ja_JP.UTF-8]などを設定します。
尚、環境変数はexportしてもコマンドラインから設定した場合、再ログイン時には設定されていませんから必要に応じて.bashrcや.bash_profileに設定しておきます。
PAGER=jless
JLESSCHARSET=japanese
export PAGER JLESSCHARSET
alias less="jless"
ページャとしてlessを利用する場合、そのままでは日本語が文字化けするものと思われますが、UNIX/Linuxにおいては、環境変数LANGの設定の他、jlessコマンドのインストール、必要であればlessコマンドとしてのalias設定、環境変数PAGER/JLESSCHARSETの設定により文字化けが解消するものと思われます。
尚、jlessの場合、環境変数JLESSCHARSETの文字コード値にはja/japanese/japanese (SJIS)/japanese (EUC-JP)などが設定できる場合もあるようですが、本来(LESSCHARSETに)設定可能な文字コードは、ascii/latin1/latin9/iso8859/ebcdic/IBM-1047/koi8-r/next/utf-8/dos/ujis/sjis...etc.です(設定ファイル等で設定し、読み込まれる際にエラーが出るなどshellにはじかれる場合には本来の設定値を設定する必要があります)。
Cygwinの場合、jlessのインストールもすることなく環境変数LESSCHARSETにdosを設定するとlessコマンドによる日本語の文字化けは解消されるかと思います。
更に「コンソール端末の文字コード設定」を一致させておくと日本語も問題なく利用できるでしょう。
例えばターミナルエミュレータでTera Term Pro(TTSSH)を利用している場合には、メニューの[設定]から[端末]を選び[漢字-受信(K)]と[漢字-送信(J)]、[ロケール(C)]と[言語コード(P)]を設定します(cygterm利用の場合は、TTSSH/Cygwinタブの言語設定参照)。
vi/vimでは、[~/.virc],[~/.vimrc]に利用したい文字コードをencoding/fileencodingに、文字コードのリストをfileencodingsに設定します。
set encoding=sjis
set fileencoding=sjis
set fileencodings=iso-2022-jp,utf-8,ucs2le,ucs-2,cp932,euc-jp,sjis
(この例はencoding/fileencodingはsjisの場合)
fileencodingsには基本的にリスト数の制限はなく可能性のある文字コードを設定しておくとvi/vimで開くファイルの文字コードをそのリストから探して自動認識してくれるようになります。
vi/vim編集中に確認するにはコマンドモードでコロンを入れてsetにencoding/fileencoding/fileencodings、またはenc/fenc/fencsを指定して[Enter]、文字コード値を設定する場合は、まさに前述の例の通りにそれぞれ=イコールを使って代入します。
但し、ファイルエンコーディングの自動認識は便利ですし、閲覧する分には特に留意することはありませんが、編集する場合には、読み込んだファイルのファイルエンコーディングとencoding/fileencodingの文字コードが異なれば、そのまま保存するとencoding/fileencodingに設定されている文字コードとなるのでその点は注意が必要です。
尚、特にASCII以外で違う文字コードの文字がある場合、ファイル破損として扱われたり、(そのファイルに関しては)文字化けの原因となる為、これらの文字コードの確定と設定は、UNIX/Linux環境を整え、使い始める前、何よりも最初に行っておいた方がベターです。
改行変換例/sedコマンド
基本的なiconvコマンド使用例
文字化けについては、改行コードと文字コードに留意する必要があり、改行コードの場合には、UNIX/Linux(LF、\n)・Windows(CRLF、\n)・Macintosh(CR、\r)での改行コードの相違を検索置換などで統一したり、ASCII文字以外の文字コード(jis,sjis,ujis,xjis.euc,utf-8,utf-16...etc.)においては、特にjis系において文字化けが起こる場合には、nkfコマンドやiconvコマンドを利用すれば対応できる場合があります。
nkfコマンドは、伝統的なコマンドですが、デフォルトでインストールされていることが少ない一方、GNU iconv含め、iconvは、より多くの環境で標準インストールされている可能性が高いコマンドです。
UNIX/Linuxコマンド及びshellにおけるiconvコマンドの基本的な使用方法は、-f/from、-t/toオプションで文字コード、当該ファイル名を指定し、リダイレクトして変換後のファイルを作成します(-f/-t未指定の場合、既定は何れも環境変数LANG等のロケールコード)。
この処理が必要な場合には、元の文字コードに戻す必要があるはずなので一時ファイルにリダイレクトした後、最終的に元ファイルの元の文字コードに変換後、一時ファイルを削除するといった処理になるでしょう。
C/C++では、iconv.hをincludeすることでiconv関数を利用することができます(man 3 iconv 他参照)。
尚、ここまでの対応で問題が解消しない場合やシェル、コマンドのメッセージに文字化けがある場合には、Cygwin日本語対応及びCygwin日本語対応の具体的な方法を参照してください。