この記事は『ゼロからはじめるLINUXサーバー構築・運用ガイド 動かしながら学ぶWEBサーバーの作り方』のまとめになります。 参照:ゼロからはじめるLINUXサーバー構築・運用ガイド 動かしながら学ぶWEBサーバーの作り方 参照:http://www.cc.kyoto-su.ac.jp/~hirai/text/shell.html シェル：コマンドを受け付けて実行するソフトウェア シェルとは、コマンドを受け付けて実行するソフトウェアのこと。 コマンドと呼ばれるプログラムの入力を受けつけ、Enterを押すことで実行される。 実行の流れ (1)プロンプト(=動作するよう促すもの)を表示('#') (2)コマンドを入力 (3)コマンドを探して実行 (4)実行結果を表示 (5)実行終了 (6)プロンプトを表示 シェルの種類:最も利用されるのはbash 種類 説明 sh Bourne shell。初版が1977年と古いシェルで、UNIX系システムで使われている。 bash 予約語や構文などの言語の基本的要素は全て Bourne shell を基に作成されており、そこに C shell や KornShell の機能なども追加・改良され作成されたシェル。多くのディストリビューションで標準となっている。 csh Bourne shell と共通の先祖を持つシェルで、言語の全体的なスタイルはC言語に似ており、UNIXユーザーには読みやすい形になっている。 tcsh cshに機能を追加する形で改良したシェル その他以下Wikipedia参照 シェル Unixシェル コマンド ・コマンド名と同じファイルの外部コマンドと、シェルに内蔵されている内部コマンドがある ・大文字と小文字は区別される ・インストールされていないコマンドを実行したりスペルミスをしている場合にはエラーが起こる ・コマンドによってはオプションや引数を指定できるものがある 書式 ## コマンド [オプション] [引数] *オプション及び引数は省略可能 参照:bash - コマンド (プログラム) の説明 - Linux コマンド集 一覧表 シェルの機能 自動補完 ・コマンドやファイル名などを自動的に補完する機能があり、入力中にタブを押すことで入力する部分の残りを自動的に補完する ・補完するコマンドやファイル名が複数ある場合には、その一覧が表示される ・実行したコマンドは保存され、あとで簡単に呼び出しができる(Ctrl + P/Ctrl + N) ・インクリメンタル検索で効率的なコマンド履歴の検索もできる(Ctrl + R) ->１文字入力するごとに、コマンドの候補を表示する ->入力した文字が履歴にない場合は、入力した文字自体も表示されない パイプ ・あるコマンドからの出力を別のコマンドに入力する仕組み ・パイプ「 | 」を使うことで複数のコマンドを１度に繋いで入力->実行できる 実行例 # コマンド1 | コマンド2 | コマンド3 =>コマンド１の処理結果をコマンド2が連続処理し、コマンド2の処理結果をコマンド3が連続処理し、コマンド3の処理結果をターミナルに表示する リダイレクト ・コマンドの実行結果をファイルに保存するときに使う機能 ・「コマンド > (or >> ) 出力先ファイル名」で実行 ・「 > 」を使うとファイルを上書きor新規のファイルが作成される ・「 >> 」に既にあるファイル名を指定すると上書きはせず、ファイルの末尾に追記する メタキャラクタ ・メタキャラクタとは、シェル上で特別な意味を持つ記号のこと ・代表的なものに「 * 」や「 ? 」がある 種類 説明 * 0文字以上の任意の文字列 ? 任意の1文字 [] []内の任意の1文字 \ メタキャラクタのエスケープ 環境変数：シェルの状態や設定値が保存される変数 ・慣例的に、環境変数には大文字が使われる(シェル変数は小文字) ・環境変数の値を表示するにはechoコマンドを使用し、環境変数名の前に「 $ 」をつける 主な環境変数 環境変数名 説明 PATH コマンドやプログラムを検索するディレクトリのリスト USER 現在のユーザ名 LANG 地域設定（言語処理方式) HOME 現在のユーザのホームディレクトリ HISTSIZE コマンド履歴の最大値 HISTFILE コマンド履歴を格納するファイル EDITOR 標準エディタ 環境変数の値の確認 ・echo $環境変数名で値の確認ができる 書式 echo $環境変数名 実行例-コマンド履歴の最大値を確認する # echo $HISTSIZE => 1000(デフォルトでは1000に設定されている) 環境変数の値の変更 ・環境変数の値を変更するにはexportコマンドを使用する 書式 # export HISTSIZE=2000 =>HISTSIZEの値を１０００から２０００に変更 ・設定を変更した環境変数の値は、シェルが終了するまで有効 ・変更した値をデフォルトに設定したい場合、「.bash_profile」というファイルの末尾に追加することで設定できる *「.bash_profile」はターミナルから以下のように開ける .bash_profileを開く vim ~/.bash_profile (vimエディタの場合) nano ~/.bash_profile (nanoエディタの場合)
この記事は『ゼロからはじめるLINUXサーバー構築・運用ガイド 動かしながら学ぶWEBサーバーの作り方』のまとめになります。
参照:ゼロからはじめるLINUXサーバー構築・運用ガイド 動かしながら学ぶWEBサーバーの作り方 参照:http://www.cc.kyoto-su.ac.jp/~hirai/text/shell.html
シェルとは、コマンドを受け付けて実行するソフトウェアのこと。 コマンドと呼ばれるプログラムの入力を受けつけ、Enterを押すことで実行される。
(1)プロンプト(=動作するよう促すもの)を表示('#') (2)コマンドを入力 (3)コマンドを探して実行 (4)実行結果を表示 (5)実行終了 (6)プロンプトを表示
その他以下Wikipedia参照 シェル Unixシェル
・コマンド名と同じファイルの外部コマンドと、シェルに内蔵されている内部コマンドがある ・大文字と小文字は区別される ・インストールされていないコマンドを実行したりスペルミスをしている場合にはエラーが起こる ・コマンドによってはオプションや引数を指定できるものがある
## コマンド [オプション] [引数] *オプション及び引数は省略可能
参照:bash - コマンド (プログラム) の説明 - Linux コマンド集 一覧表
・コマンドやファイル名などを自動的に補完する機能があり、入力中にタブを押すことで入力する部分の残りを自動的に補完する ・補完するコマンドやファイル名が複数ある場合には、その一覧が表示される ・実行したコマンドは保存され、あとで簡単に呼び出しができる(Ctrl + P/Ctrl + N) ・インクリメンタル検索で効率的なコマンド履歴の検索もできる(Ctrl + R) ->１文字入力するごとに、コマンドの候補を表示する ->入力した文字が履歴にない場合は、入力した文字自体も表示されない
・あるコマンドからの出力を別のコマンドに入力する仕組み ・パイプ「 | 」を使うことで複数のコマンドを１度に繋いで入力->実行できる
# コマンド1 | コマンド2 | コマンド3 =>コマンド１の処理結果をコマンド2が連続処理し、コマンド2の処理結果をコマンド3が連続処理し、コマンド3の処理結果をターミナルに表示する
・コマンドの実行結果をファイルに保存するときに使う機能 ・「コマンド > (or >> ) 出力先ファイル名」で実行 ・「 > 」を使うとファイルを上書きor新規のファイルが作成される ・「 >> 」に既にあるファイル名を指定すると上書きはせず、ファイルの末尾に追記する
・メタキャラクタとは、シェル上で特別な意味を持つ記号のこと ・代表的なものに「 * 」や「 ? 」がある
・慣例的に、環境変数には大文字が使われる(シェル変数は小文字) ・環境変数の値を表示するにはechoコマンドを使用し、環境変数名の前に「 $ 」をつける
・echo $環境変数名で値の確認ができる
echo $環境変数名
# echo $HISTSIZE => 1000(デフォルトでは1000に設定されている)
・環境変数の値を変更するにはexportコマンドを使用する
# export HISTSIZE=2000 =>HISTSIZEの値を１０００から２０００に変更
・設定を変更した環境変数の値は、シェルが終了するまで有効 ・変更した値をデフォルトに設定したい場合、「.bash_profile」というファイルの末尾に追加することで設定できる *「.bash_profile」はターミナルから以下のように開ける
vim ~/.bash_profile (vimエディタの場合) nano ~/.bash_profile (nanoエディタの場合)
Aaaa
独自研究ですので、間違っていたらご指摘ください。 デバイスドライバの仕組み iostat を見る前に、デバイスドライバの層構造を確認しましょう。 システムコール ------------------------------------------- VFS ------------------------------------------- ファイルシステム（ext3, xfs など） ------------------------------------------- ブロックデバイス汎用ドライバ + ------------------------------------------- | SCSI 上位層（sd*ドライバ、st*ドライバなど） | ------------------------------------------- | iostat で SCSI 中間層 | 計上 ------------------------------------------- | SCSI 下位層（lpfc ドライバなど） | ------------------------------------------- | 物理デバイス + LVM や dm-multipath などがあると、さらに層は増えます。 これらの層の実装が複雑に絡み合って I/O 処理が実現されております。 iostat の値の計上はもっぱらブロックデバイス汎用ドライバのレイヤで行われます。 つまり、iostat の項目には、ファイルシステムで要した時間などは一切含まれていないということです。 また、SCSI レイヤなどでの細かい粒度での値も一切記録されていません。 ブロックデバイス汎用ドライバの仕組み ブロックデバイスドライバは上位層から受け取った bio （I/O 操作要求の単位）をもとに、 複数の bio からなる request を作成し、request queue に投入します。 （bio を既存の request に結合する場合もあります。） 詳細は「詳解 Linux カーネル」の第 13 章が参考になります。 iostat はここで作成された request を I/O 操作の基本の単位として計算します。 +-----+ +-----+ +-----+ | APP | | APP | | APP | +-----+ +-----+ +-----+ 上 | | | 位 +-----------+-----------+ 層 | | ----------------------------------------- bio ------------------------------------ | ブ V ロ make_request_fn() ---- blk_queue_bio() : ッ bio から request を新規作成、 ク もしくは既存の request へ併合（先頭に併合するなら front_merge, 末尾なら back_merge という） + デ | : バ V : イ <----------------------------------------------------------------- : ス < request_queue : 汎 <----------+-+----------+-+----------+-+----------+-+------------- : 用 | request | | request | | request | | request | | request | + : ド +----------+ +----------+ +----------+ +----------+ +----------+ : : ラ |bio|bio|..| |bio|bio|..| |bio|bio|..| |bio|bio|..| |bio|bio|..| : : イ +---+---+--+ +---+---+--+ +---+---+--+ +---+---+--+ +---+---+--+ : : バ ↑ + : : ｜ : : : await ------------｜------------------------------------------------------------------- : : : ｜ : : : ブロック : : : 下 ↓ : wsec/s : r/s : 位 +--------------------------------------------------------------+ : rsec/s : w/s : 層 | SCSI | : svctm : : +--------------------------------------------------------------+ : : : ↑ : : : SCSI コマンド : : : ↓ : : : +--------------------------------------------------------------+ : : : | DISC | + + + +--------------------------------------------------------------+ iostat 値はどこから来るのか 以下は iostat の実行例です。 # iostat -dx Linux 3.10.0-327.el7.x86_64 (******) 2019年05月20日 _x86_64_ (2 CPU) Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util fd0 0.00 0.00 0.00 0.00 0.00 0.00 8.00 0.00 57.00 57.00 0.00 57.00 0.00 sdb 0.00 0.00 0.02 0.00 0.16 0.00 15.40 0.00 1.01 1.01 0.00 0.81 0.00 sda 0.00 0.15 1.08 1.74 26.28 12.53 27.49 0.02 7.34 2.48 10.35 1.34 0.38 これらの値は /proc/diskstats から取得されます。 /proc/diskstats は統計値なので、iostat に出力する際には /proc/diskstats を 2 回採取し、その差から増加量を算出しています。 # cat /proc/diskstats 2 0 fd0 2 0 16 114 0 0 0 0 0 114 114 8 16 sdb 493 0 7592 500 0 0 0 0 0 399 499 8 17 sdb1 167 0 2656 168 0 0 0 0 0 160 168 8 18 sdb2 163 0 2624 176 0 0 0 0 0 158 175 8 0 sda 26012 29 1266124 64425 42214 3652 606259 436725 2 91582 4875552 487555 8 1 sda1 2311 0 59398 3163 4 0 4096 85 0 2269 3242 8 2 sda2 22131 29 1180448 59310 42203 3652 602149 436616 2 88931 482037 8 3 sda3 163 0 2624 201 0 0 0 0 0 188 200 8 4 sda4 1316 0 22046 1669 7 0 14 24 0 1343 1690 diskstats の各項目の説明は以下にあります。 https://www.kernel.org/doc/Documentation/iostats.txt svctm、await について たとえば、svctm、await は /proc/diskstats の値をもとに、以下のように計算されます。 ■ 単位時間に完了した I/O リクエスト数が 1 以上なら svctm = tot_ticks / nr_ios await = (rd_ticks + wr_ticks) / nr_ios ■ 単位時間に完了した I/O リクエスト数が 0 なら svctm = 0.0 await = 0.0 nr_ios : 単位時間中に完了した I/O リクエスト数 rd_ticks : 単位時間中に完了した読み込みリクエストが、生成されてから完了するまでに要した時間 wr_ticks : 単位時間中に完了した書き込みリクエストが、生成されてから完了するまでに要した時間 tot_ticks : 単位時間中にブロックデバイスドライバ層より下のレイヤで I/O に要した時間 /proc/diskstats iostat の各項目を理解するにあたって大切なのは、/proc/diskstats の各項目の値がどのタイミングでどのように増えるかです。 /proc/diskstats の値はもっぱらカーネルのブロックデバイス汎用ドライバ層で計上されます。 ※/proc/ 以下は、getdents(2) などで要求されるたび、カーネルがオンデマンドで作成しています。 いずれも実際に存在するファイルではありません。 統計情報も、オンデマンドで fake なファイルを作って、カーネルがメモリ上に保持している値を載せて、アプリケーションに返しています。 ソースの調査結果は割愛しますが、以下のように計上されております。 rd_ticks, wr_ticks ： request 作成時の時刻と、完了時の時刻の差分から計上 tot_ticks ： 計上用関数を都度呼び出し、呼び出したときに I/O 中のフラグ（in_flight）が立っていれば計上 図にすると以下のようになります。 上位層 \ / \ / ===============================\==============================================/============ bio / ブロック \ / デバイス blk_make_request() request ........ rd_ticks, wr_ticks ......../ blk_finish_request() レイヤ \ / \ / ----------------- / request queue / ----------------- / \ +-+ / blk_dequeue_request() \.tot_ticks./ \.tot_ticks./ =========================================\=========/=====\=========/================================= SCSI \ / \ / レイヤ以下 \-I/O-/ \-I/O-/
独自研究ですので、間違っていたらご指摘ください。
iostat を見る前に、デバイスドライバの層構造を確認しましょう。
システムコール ------------------------------------------- VFS ------------------------------------------- ファイルシステム（ext3, xfs など） ------------------------------------------- ブロックデバイス汎用ドライバ + ------------------------------------------- | SCSI 上位層（sd*ドライバ、st*ドライバなど） | ------------------------------------------- | iostat で SCSI 中間層 | 計上 ------------------------------------------- | SCSI 下位層（lpfc ドライバなど） | ------------------------------------------- | 物理デバイス +
LVM や dm-multipath などがあると、さらに層は増えます。 これらの層の実装が複雑に絡み合って I/O 処理が実現されております。
iostat の値の計上はもっぱらブロックデバイス汎用ドライバのレイヤで行われます。
つまり、iostat の項目には、ファイルシステムで要した時間などは一切含まれていないということです。 また、SCSI レイヤなどでの細かい粒度での値も一切記録されていません。
ブロックデバイスドライバは上位層から受け取った bio （I/O 操作要求の単位）をもとに、 複数の bio からなる request を作成し、request queue に投入します。 （bio を既存の request に結合する場合もあります。）
詳細は「詳解 Linux カーネル」の第 13 章が参考になります。
iostat はここで作成された request を I/O 操作の基本の単位として計算します。
+-----+ +-----+ +-----+ | APP | | APP | | APP | +-----+ +-----+ +-----+ 上 | | | 位 +-----------+-----------+ 層 | | ----------------------------------------- bio ------------------------------------ | ブ V ロ make_request_fn() ---- blk_queue_bio() : ッ bio から request を新規作成、 ク もしくは既存の request へ併合（先頭に併合するなら front_merge, 末尾なら back_merge という） + デ | : バ V : イ <----------------------------------------------------------------- : ス < request_queue : 汎 <----------+-+----------+-+----------+-+----------+-+------------- : 用 | request | | request | | request | | request | | request | + : ド +----------+ +----------+ +----------+ +----------+ +----------+ : : ラ |bio|bio|..| |bio|bio|..| |bio|bio|..| |bio|bio|..| |bio|bio|..| : : イ +---+---+--+ +---+---+--+ +---+---+--+ +---+---+--+ +---+---+--+ : : バ ↑ + : : ｜ : : : await ------------｜------------------------------------------------------------------- : : : ｜ : : : ブロック : : : 下 ↓ : wsec/s : r/s : 位 +--------------------------------------------------------------+ : rsec/s : w/s : 層 | SCSI | : svctm : : +--------------------------------------------------------------+ : : : ↑ : : : SCSI コマンド : : : ↓ : : : +--------------------------------------------------------------+ : : : | DISC | + + + +--------------------------------------------------------------+
以下は iostat の実行例です。
# iostat -dx Linux 3.10.0-327.el7.x86_64 (******) 2019年05月20日 _x86_64_ (2 CPU) Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util fd0 0.00 0.00 0.00 0.00 0.00 0.00 8.00 0.00 57.00 57.00 0.00 57.00 0.00 sdb 0.00 0.00 0.02 0.00 0.16 0.00 15.40 0.00 1.01 1.01 0.00 0.81 0.00 sda 0.00 0.15 1.08 1.74 26.28 12.53 27.49 0.02 7.34 2.48 10.35 1.34 0.38
これらの値は /proc/diskstats から取得されます。 /proc/diskstats は統計値なので、iostat に出力する際には /proc/diskstats を 2 回採取し、その差から増加量を算出しています。
# cat /proc/diskstats 2 0 fd0 2 0 16 114 0 0 0 0 0 114 114 8 16 sdb 493 0 7592 500 0 0 0 0 0 399 499 8 17 sdb1 167 0 2656 168 0 0 0 0 0 160 168 8 18 sdb2 163 0 2624 176 0 0 0 0 0 158 175 8 0 sda 26012 29 1266124 64425 42214 3652 606259 436725 2 91582 4875552 487555 8 1 sda1 2311 0 59398 3163 4 0 4096 85 0 2269 3242 8 2 sda2 22131 29 1180448 59310 42203 3652 602149 436616 2 88931 482037 8 3 sda3 163 0 2624 201 0 0 0 0 0 188 200 8 4 sda4 1316 0 22046 1669 7 0 14 24 0 1343 1690
diskstats の各項目の説明は以下にあります。
https://www.kernel.org/doc/Documentation/iostats.txt
たとえば、svctm、await は /proc/diskstats の値をもとに、以下のように計算されます。
■ 単位時間に完了した I/O リクエスト数が 1 以上なら svctm = tot_ticks / nr_ios await = (rd_ticks + wr_ticks) / nr_ios ■ 単位時間に完了した I/O リクエスト数が 0 なら svctm = 0.0 await = 0.0
iostat の各項目を理解するにあたって大切なのは、/proc/diskstats の各項目の値がどのタイミングでどのように増えるかです。 /proc/diskstats の値はもっぱらカーネルのブロックデバイス汎用ドライバ層で計上されます。
※/proc/ 以下は、getdents(2) などで要求されるたび、カーネルがオンデマンドで作成しています。 いずれも実際に存在するファイルではありません。 統計情報も、オンデマンドで fake なファイルを作って、カーネルがメモリ上に保持している値を載せて、アプリケーションに返しています。
ソースの調査結果は割愛しますが、以下のように計上されております。
図にすると以下のようになります。
上位層 \ / \ / ===============================\==============================================/============ bio / ブロック \ / デバイス blk_make_request() request ........ rd_ticks, wr_ticks ......../ blk_finish_request() レイヤ \ / \ / ----------------- / request queue / ----------------- / \ +-+ / blk_dequeue_request() \.tot_ticks./ \.tot_ticks./ =========================================\=========/=====\=========/================================= SCSI \ / \ / レイヤ以下 \-I/O-/ \-I/O-/
主なコマンド コマンド 内容 apt-get ~~ ~~はpackage名(sudoが必要) mkdir ~~ ~~という名前のディレクトリ作成 rm -r ~~ ~~というファイルORディレクトリ削除 cd ~~ ~~に移動（tabキーである程度入力してあると予測判定して入力してくれる） ls 今いる場所のファイルORディレクトリリスト sudo -i rootユーザーになる荒技(使わない方がいいらしい) sudo ~~ ~~にコマンドを入れるとroot権限で実行してくれる dpkg -l apt-getでinstallしたものがリストで観れる pwd 今いる場所のパスを表示 unzip ~~ ~~にzipファイルを入れると解凍してくれる apt-get update 毎回打っとくおまじないコマンド（パッケージの更新）
何が起こっていたか、とその原因 Progateは外部ライブラリのAceエディタというものを使っていて、そのAceエディタがmonospace(等幅フォント)なフォントをローカルに参照しにいくため、等幅フォントのインストール加減によっては等幅フォント以外のフォントでレンダリングされるという現象だった。 解決策 AceエディタのfontのCSSは以下のようになっています。 { font: 12px/normal 'Monaco', 'Menlo', 'Ubuntu Mono', 'Consolas', 'source-code-pro', monospace; } ですので、monacoフォントをインストールしてchrome再起動で解決します。 Arch系のOSの場合 AURにttf-monacoというパッケージがあるので、ソフトウェアの追加と削除からとか、yayとかaurmanを使って入れてください。 Ubuntuの場合 curl -kL https://raw.github.com/cstrap/monaco-font/master/install-font-ubuntu.sh | bash ついでにCircleCIの公式ページもぶっ壊れてる時 ttf-material-icon というパッケージがあるのでそれをインストールしましょう。
Progateは外部ライブラリのAceエディタというものを使っていて、そのAceエディタがmonospace(等幅フォント)なフォントをローカルに参照しにいくため、等幅フォントのインストール加減によっては等幅フォント以外のフォントでレンダリングされるという現象だった。
AceエディタのfontのCSSは以下のようになっています。
{ font: 12px/normal 'Monaco', 'Menlo', 'Ubuntu Mono', 'Consolas', 'source-code-pro', monospace; }
ですので、monacoフォントをインストールしてchrome再起動で解決します。
AURにttf-monacoというパッケージがあるので、ソフトウェアの追加と削除からとか、yayとかaurmanを使って入れてください。
curl -kL https://raw.github.com/cstrap/monaco-font/master/install-font-ubuntu.sh | bash
ttf-material-icon というパッケージがあるのでそれをインストールしましょう。
ttf-material-icon
いままでつかう機会のなかったhistory コマンド はたして使いみちはあるんかという話。 history コマンドとは これまでにつかったコマンドのヒストリを表示する testuser@Inspiron-3180:~$ history 1 ls 2 clear 3 history さらに ”！”＋ N (コマンド履歴にひだりについてる数字) でそのコマンドを実行できる testuser@Inspiron-3180:~$ !1 ls けっこう前につかったコマンドでまた使いたいなーってときには つかえるかも でも３，４回前につかったコマンドなら上キーでよびだしたほうがはやい !! 直前につかったコマンドをよびだす 上キーでよびだしたほうがはやい しかも！でよびだすと、確認なしでコマンドが実行されるのでリスキー !?string? stringに入力したキーワードでコマンドりれきを検索 さいしょに該当したコマンドを実行する testuser@Inspiron-3180:~$ history 1 ls 2 clear 3 history 4 ls 5 testuser@Inspiron-3180:~$ history 6 ls 7 date 8 clear 9 history 10 hostname 11 hostnamectl 12 hitstory 13 history testuser@Inspiron-3180:~$ !?host? hostnamectl Static hostname: aki-Inspiron-3180 Icon name: computer-laptop Chassis: laptop Machine ID: 34df0f2b36974d1e8def4ca4f49a8928 Boot ID: 1e92d1839a964ba799059823c1e30690 Operating System: Ubuntu 18.04.2 LTS Kernel: Linux 4.15.0-29-generic Architecture: x86-64 hostname(古い), hostnamectl（新しい）が履歴にある状態で !?host?で検索した。 -> hostnnamectl（新しいほう）が実行された うん。 検索するだけならいいけど実行までされるのはどうかな・・・ 結論 historyコマンドは（だいぶ）前のコマンド思い出したいときにつかえる 履歴からのコマンド実行はしないほうが無難
いままでつかう機会のなかったhistory コマンド はたして使いみちはあるんかという話。
これまでにつかったコマンドのヒストリを表示する
testuser@Inspiron-3180:~$ history 1 ls 2 clear 3 history
さらに ”！”＋ N (コマンド履歴にひだりについてる数字) でそのコマンドを実行できる
testuser@Inspiron-3180:~$ !1 ls
けっこう前につかったコマンドでまた使いたいなーってときには つかえるかも でも３，４回前につかったコマンドなら上キーでよびだしたほうがはやい
!! 直前につかったコマンドをよびだす 上キーでよびだしたほうがはやい
しかも！でよびだすと、確認なしでコマンドが実行されるのでリスキー
!?string? stringに入力したキーワードでコマンドりれきを検索 さいしょに該当したコマンドを実行する
testuser@Inspiron-3180:~$ history 1 ls 2 clear 3 history 4 ls 5 testuser@Inspiron-3180:~$ history 6 ls 7 date 8 clear 9 history 10 hostname 11 hostnamectl 12 hitstory 13 history testuser@Inspiron-3180:~$ !?host? hostnamectl Static hostname: aki-Inspiron-3180 Icon name: computer-laptop Chassis: laptop Machine ID: 34df0f2b36974d1e8def4ca4f49a8928 Boot ID: 1e92d1839a964ba799059823c1e30690 Operating System: Ubuntu 18.04.2 LTS Kernel: Linux 4.15.0-29-generic Architecture: x86-64
hostname(古い), hostnamectl（新しい）が履歴にある状態で !?host?で検索した。 -> hostnnamectl（新しいほう）が実行された うん。
検索するだけならいいけど実行までされるのはどうかな・・・
historyコマンドは（だいぶ）前のコマンド思い出したいときにつかえる 履歴からのコマンド実行はしないほうが無難
supervisorの *.conf配置ファイルのdirectoryを編集する ↓このように [program:HelloWorld] directory=/home/ec2-user/GoCode/hello/ command=go run /home/ec2-user/GoCode/hello/HelloWorld.go autostart=true autorestart=true startsecs=10 stdout_logfile=/var/log/HelloWorld.log stdout_logfile_maxbytes=1MB stdout_logfile_backups=10 stdout_capture_maxbytes=1MB stderr_logfile=/var/log/HelloWorld.log stderr_logfile_maxbytes=1MB stderr_logfile_backups=10 stderr_capture_maxbytes=1MB
supervisorの *.conf配置ファイルのdirectoryを編集する ↓このように
*.conf
[program:HelloWorld] directory=/home/ec2-user/GoCode/hello/ command=go run /home/ec2-user/GoCode/hello/HelloWorld.go autostart=true autorestart=true startsecs=10 stdout_logfile=/var/log/HelloWorld.log stdout_logfile_maxbytes=1MB stdout_logfile_backups=10 stdout_capture_maxbytes=1MB stderr_logfile=/var/log/HelloWorld.log stderr_logfile_maxbytes=1MB stderr_logfile_backups=10 stderr_capture_maxbytes=1MB
go envで環境変数を確認 vim ~/.bashrcでPATHを変更 重要なPATH： GOROOT＝$HOME/local/go //goの位置 PATH=$PATH:$GOROOT/bin export GOPATH=projectDir export GOBIN=projectDir/din プロジェクト中にには{pkg,src,bin}のような三つのフォルダーがあります。 *.go-------src buided file--------bin
go envで環境変数を確認
go env
vim ~/.bashrcでPATHを変更
重要なPATH：
GOROOT＝$HOME/local/go //goの位置 PATH=$PATH:$GOROOT/bin export GOPATH=projectDir export GOBIN=projectDir/din
プロジェクト中にには{pkg,src,bin}のような三つのフォルダーがあります。 *.go-------src buided file--------bin
