Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

[インデックス 15544] ファイルの概要

このコミットは、Go言語のcmd/cgoツールにおけるutil.goファイル内の外部コマンド実行ロジックを改善するものです。具体的には、os/execパッケージの機能を独自に再実装していた部分を削除し、標準ライブラリのos/execパッケージを適切に利用するように変更しています。これにより、コードの簡潔性、堅牢性、保守性が向上しています。

コミット

commit 80d2eac14d973e672d8d60780c67283fcc58d933
Author: Rémy Oudompheng <oudomphe@phare.normalesup.org>
Date:   Fri Mar 1 15:04:14 2013 -0500

    cmd/cgo: don't reimplement os/exec in util.go.
    
    R=golang-dev, rsc
    CC=golang-dev
    https://golang.org/cl/7450049

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/80d2eac14d973e672d8d60780c67283fcc58d933

元コミット内容

cmd/cgo: don't reimplement os/exec in util.go.

このコミットメッセージは、「cmd/cgoにおいて、util.go内でos/execを再実装するのをやめる」という簡潔な内容です。これは、既存のコードがGo標準ライブラリのos/execパッケージが提供する機能(外部プロセスの実行、標準入出力のリダイレクト、プロセスの待機など)を独自に、かつ冗長に実装していたことを示唆しています。

変更の背景

変更の背景には、主に以下の点が挙げられます。

  1. 冗長なコードの排除: util.go内のrun関数は、外部コマンドを実行するためにos.Pipeos.StartProcessioutil.ReadAllなどを直接使用し、標準入出力のリダイレクトやプロセスの待機といった処理を独自に実装していました。これは、Goの標準ライブラリであるos/execパッケージが既に提供している機能の再実装であり、コードの冗長性を招いていました。
  2. 堅牢性の向上: 独自の実装は、エラーハンドリングやエッジケースの考慮が不十分である可能性があり、バグや予期せぬ動作につながるリスクがありました。os/execパッケージは、Goのコア開発チームによってメンテナンスされており、様々なプラットフォームでの動作やエラーケースが考慮されています。これを利用することで、より堅牢な外部コマンド実行処理を実現できます。
  3. 保守性の向上: 標準ライブラリの機能を使用することで、コードの意図が明確になり、他のGo開発者にとっても理解しやすくなります。これにより、将来的なメンテナンスや機能追加が容易になります。
  4. Goのイディオムへの準拠: Go言語では、可能な限り標準ライブラリや既存のパッケージを活用することが推奨されます。os/execの再実装は、このイディオムに反していました。

このコミットは、これらの問題を解決し、cmd/cgoのコードベースの品質を向上させることを目的としています。

前提知識の解説

このコミットを理解するためには、以下のGo言語のパッケージと概念に関する知識が必要です。

  • os/execパッケージ:
    • Go言語で外部コマンドを実行するための標準ライブラリパッケージです。
    • exec.Command関数は、実行するコマンドと引数を指定してCmd構造体を作成します。
    • Cmd構造体には、標準入力 (Stdin)、標準出力 (Stdout)、標準エラー出力 (Stderr) を設定するためのフィールドがあります。これらはio.Readerio.Writerインターフェースを満たすオブジェクト(例: bytes.Buffer)に設定できます。
    • Cmd.Run()メソッドは、コマンドを実行し、完了するまで待機します。コマンドが正常に終了しなかった場合(終了ステータスが0以外の場合)はエラーを返します。
    • exec.ExitErrorは、コマンドがゼロ以外の終了ステータスで終了した場合にRunメソッドが返すエラーの型です。このエラーをチェックすることで、コマンドの実行自体は成功したが、内部でエラーが発生したかどうかを判断できます。
    • Cmd.ProcessState.Success()メソッドは、コマンドが正常に終了したかどうか(終了ステータスが0であるか)を返します。
  • os.Pipe():
    • パイプを作成するための関数です。パイプは、一方の端に書き込まれたデータがもう一方の端から読み取れるようにする、プロセス間通信のメカニズムです。
    • r, w, err := os.Pipe()のように呼び出され、読み取り側 (r) と書き込み側 (w) の*os.Fileオブジェクトを返します。
  • os.StartProcess():
    • 新しいプロセスを開始するための低レベルな関数です。
    • os.StartProcess(name, argv, attr)のように呼び出され、実行するプログラムのパス、引数、およびプロセス属性 (os.ProcAttr) を指定します。
    • os.ProcAttr構造体には、新しいプロセスの標準入出力ファイルディスクリプタを設定するためのFilesフィールドがあります。
  • io/ioutilパッケージ (Go 1.16以降はioosに統合):
    • ファイルやストリームからの読み書きを補助するユーティリティ関数を提供していました。
    • ioutil.ReadAll(r io.Reader)は、io.ReaderからEOF(End Of File)に達するまですべてのデータを読み込み、バイトスライスとして返します。
  • bytes.Buffer:
    • 可変長のバイトバッファを実装する構造体です。
    • io.Writerインターフェースとio.Readerインターフェースの両方を満たすため、os/exec.CmdStdoutStderrに設定してコマンドの出力をキャプチャしたり、Stdinに設定してコマンドにデータを渡したりするのに便利です。
  • cmd/cgo:
    • Go言語のツールチェーンの一部であり、C言語のコードをGoプログラムから呼び出すためのCgoツールに関連するコマンドです。
    • Cgoは、GoとC/C++の相互運用を可能にするための重要なツールであり、その内部で外部コマンド(Cコンパイラなど)を実行する必要があるため、このutil.goのようなヘルパー関数が存在していました。

技術的詳細

このコミットの技術的な核心は、外部コマンド実行の抽象化レベルの変更にあります。

変更前 (run関数の旧実装):

変更前のrun関数は、Goの低レベルなプロセス管理APIを直接使用していました。

  1. exec.LookPath(argv[0]): 実行するコマンドのパスをシステムPATHから検索します。これはos/execパッケージの機能ですが、その後のプロセス実行は手動で行われます。
  2. os.Pipe()の多用: 標準入力、標準出力、標準エラー出力のためにそれぞれ3組のパイプ(読み取り側と書き込み側)を作成していました。
    • r0, w0:コマンドの標準入力用。w0に書き込んだデータがコマンドの標準入力に渡されます。
    • r1, w1:コマンドの標準出力用。コマンドが標準出力に書き込んだデータがr1から読み取られます。
    • r2, w2:コマンドの標準エラー出力用。コマンドが標準エラー出力に書き込んだデータがr2から読み取られます。
  3. os.StartProcess(): 新しいプロセスを直接開始します。os.ProcAttr構造体のFilesフィールドを使って、作成したパイプの適切な端(コマンドの標準入力にはr0、標準出力にはw1、標準エラー出力にはw2)を新しいプロセスに渡していました。
  4. パイプのクローズ: os.StartProcess呼び出し後、親プロセス側で不要になったパイプの端(r0, w1, w2)をすぐにクローズしていました。これは、子プロセスがこれらのファイルディスクリプタを継承するため、親プロセス側で開いたままにしておくとリソースリークやデッドロックの原因となる可能性があるためです。
  5. ゴルーチンとチャネルによるI/O処理:
    • stdinデータをw0に書き込み、w0をクローズするゴルーチン。
    • r1から標準出力をioutil.ReadAllで読み取るゴルーチン。
    • メインゴルーチンでr2から標準エラー出力をioutil.ReadAllで読み取る。
    • チャネル (c) を使用して、I/Oゴルーチンの完了を待機していました。
  6. p.Wait(): プロセスが終了するまで待機し、その終了ステータスを取得します。
  7. state.Success(): プロセスの終了ステータスが成功(0)であったかを確認します。

この旧実装は、低レベルなAPIを直接操作するため、多くのボイラープレートコードが必要であり、パイプの管理、ゴルーチン間の同期、エラーハンドリングなどが複雑になりがちでした。特に、パイプのクローズ順序やデッドロックの回避には細心の注意が必要です。

変更後 (run関数の新実装):

変更後のrun関数は、os/execパッケージのより高レベルな抽象化を利用しています。

  1. exec.Command(argv[0], argv[1:]...): 実行するコマンドと引数を指定して*exec.Cmdオブジェクトを生成します。これにより、コマンドのパス検索や引数のパースが自動的に行われます。
  2. p.Stdin = bytes.NewReader(stdin): コマンドの標準入力に渡すデータをbytes.Readerとして設定します。bytes.Readerio.Readerインターフェースを満たします。
  3. var bout, berr bytes.Buffer: 標準出力と標準エラー出力をキャプチャするために、それぞれbytes.Bufferインスタンスを作成します。
  4. p.Stdout = &boutp.Stderr = &berr: bytes.Bufferio.Writerインターフェースを満たすため、コマンドの標準出力と標準エラー出力の宛先として直接設定できます。これにより、パイプを手動で作成・管理する必要がなくなります。
  5. err := p.Run(): コマンドを実行し、完了するまで待機します。このメソッドは、標準入出力の処理、プロセスの開始と待機、終了ステータスの取得など、以前の手動で行っていたすべてのステップを内部で処理します。
  6. エラーハンドリング:
    • if _, ok := err.(*exec.ExitError); err != nil && !okp.Run()が返すエラーをチェックします。exec.ExitErrorは、コマンドがゼロ以外の終了ステータスで終了した場合に返されるエラーです。この条件は、「エラーが発生したが、それがexec.ExitErrorではない場合(つまり、コマンドの実行自体が失敗した場合)」にfatalfを呼び出すことを意味します。これにより、コマンドが正常に実行されたが、内部でエラーコードを返したケースと、コマンドの起動自体に失敗したケースを区別できます。
  7. ok = p.ProcessState.Success(): コマンドが正常に終了したかどうかをProcessState.Success()メソッドで確認します。
  8. stdout, stderr = bout.Bytes(), berr.Bytes(): bytes.Bufferからキャプチャした標準出力と標準エラー出力のデータをバイトスライスとして取得します。

この新実装は、os/execパッケージの提供する高レベルなAPIを活用することで、コード量を大幅に削減し、複雑なパイプ管理やゴルーチン同期のロジックを排除しています。これにより、コードはより簡潔で読みやすく、堅牢性が向上しています。

コアとなるコードの変更箇所

--- a/src/cmd/cgo/util.go
+++ b/src/cmd/cgo/util.go
@@ -5,9 +5,9 @@
 package main
 
 import (
+\t"bytes"
 \t"fmt"
 \t"go/token"
-\t"io/ioutil"
 \t"os"
 \t"os/exec"
 )
@@ -16,50 +16,17 @@ import (
 // It returns the output to standard output and standard error.
 // ok indicates whether the command exited successfully.
 func run(stdin []byte, argv []string) (stdout, stderr []byte, ok bool) {
-\tcmd, err := exec.LookPath(argv[0])
-\tif err != nil {\n-\t\tfatalf("exec %s: %s", argv[0], err)\n-\t}\n-\tr0, w0, err := os.Pipe()\n-\tif err != nil {\n-\t\tfatalf("%s", err)\n-\t}\n-\tr1, w1, err := os.Pipe()\n-\tif err != nil {\n-\t\tfatalf("%s", err)\n-\t}\n-\tr2, w2, err := os.Pipe()\n-\tif err != nil {\n-\t\tfatalf("%s", err)\n-\t}\n-\tp, err := os.StartProcess(cmd, argv, &os.ProcAttr{Files: []*os.File{r0, w1, w2}})\n-\tif err != nil {\n-\t\tfatalf("%s", err)\n-\t}\n-\tr0.Close()\n-\tw1.Close()\n-\tw2.Close()\n-\tc := make(chan bool)\n-\tgo func() {\n-\t\tw0.Write(stdin)\n-\t\tw0.Close()\n-\t\tc <- true\n-\t}()\n-\tgo func() {\n-\t\tstdout, _ = ioutil.ReadAll(r1)\n-\t\tr1.Close()\n-\t\tc <- true\n-\t}()\n-\tstderr, _ = ioutil.ReadAll(r2)\n-\tr2.Close()\n-\t<-c\n-\t<-c\n-\n-\tstate, err := p.Wait()\n-\tif err != nil {\n+\tp := exec.Command(argv[0], argv[1:]...)\n+\tp.Stdin = bytes.NewReader(stdin)\n+\tvar bout, berr bytes.Buffer\n+\tp.Stdout = &bout\n+\tp.Stderr = &berr\n+\terr := p.Run()\n+\tif _, ok := err.(*exec.ExitError); err != nil && !ok {\n \t\tfatalf("%s", err)\n \t}\n-\tok = state.Success()\n+\tok = p.ProcessState.Success()\n+\tstdout, stderr = bout.Bytes(), berr.Bytes()\n \treturn\n }\n \n```

## コアとなるコードの解説

`run`関数は、与えられた`stdin`データと`argv`(コマンドと引数のリスト)を使って外部コマンドを実行し、その標準出力、標準エラー出力、および成功したかどうかを示すブール値を返します。

**変更点:**

1.  **インポートの変更**:
    *   `"io/ioutil"`の削除: `ioutil.ReadAll`が不要になったため。
    *   `"bytes"`の追加: `bytes.Buffer`と`bytes.NewReader`を使用するため。

2.  **`run`関数の実装の全面的な書き換え**:

    **旧実装(削除された部分)**:
    *   `exec.LookPath`でコマンドのパスを検索。
    *   `os.Pipe()`を3回呼び出して、標準入出力用のパイプをそれぞれ作成。
    *   `os.StartProcess()`で新しいプロセスを起動し、手動でパイプを`Files`に割り当て。
    *   パイプの読み書き側を適切にクローズ。
    *   ゴルーチンを2つ起動し、それぞれ標準入力への書き込みと標準出力からの読み込みを非同期で行う。
    *   メインゴルーチンで標準エラー出力からの読み込みを行う。
    *   チャネルを使ってゴルーチンの完了を待機。
    *   `p.Wait()`でプロセスの終了を待機し、`state.Success()`で結果を判定。
    *   これらの処理は、低レベルなAPIを直接操作するため、コードが長く、複雑で、エラーハンドリングも煩雑でした。

    **新実装(追加された部分)**:
    *   `p := exec.Command(argv[0], argv[1:]...)`: `exec.Command`を使って、実行するコマンドと引数を指定し、`Cmd`構造体のインスタンスを作成します。これにより、コマンドのパス解決や引数の処理が`os/exec`パッケージによって自動的に行われます。
    *   `p.Stdin = bytes.NewReader(stdin)`: コマンドの標準入力として、与えられた`stdin`バイトスライスを`bytes.NewReader`でラップしたものを設定します。これにより、`stdin`データがコマンドに渡されます。
    *   `var bout, berr bytes.Buffer`: コマンドの標準出力と標準エラー出力をキャプチャするために、`bytes.Buffer`型の変数をそれぞれ宣言します。
    *   `p.Stdout = &bout`: コマンドの標準出力の宛先を`bout`(`bytes.Buffer`)に設定します。コマンドが標準出力に書き込んだデータは`bout`に蓄積されます。
    *   `p.Stderr = &berr`: コマンドの標準エラー出力の宛先を`berr`(`bytes.Buffer`)に設定します。コマンドが標準エラー出力に書き込んだデータは`berr`に蓄積されます。
    *   `err := p.Run()`: `Cmd`オブジェクトの`Run()`メソッドを呼び出します。このメソッドは、コマンドの実行、標準入出力のリダイレクト、プロセスの終了待機、終了ステータスの取得など、以前の手動で行っていたすべての複雑な処理を内部で実行します。
    *   `if _, ok := err.(*exec.ExitError); err != nil && !ok`: `Run()`メソッドが返したエラーをチェックします。もしエラーが`nil`でなく、かつ`*exec.ExitError`型ではない場合(つまり、コマンドの起動自体に失敗した場合)、`fatalf`を呼び出して致命的なエラーとして扱います。`exec.ExitError`は、コマンドがゼロ以外の終了コードで終了した場合に返されるため、これはコマンドが正常に実行されたが、内部でエラーを報告したケースとは区別されます。
    *   `ok = p.ProcessState.Success()`: コマンドが正常に終了したかどうか(終了ステータスが0であるか)を`p.ProcessState.Success()`メソッドで確認し、`ok`変数に設定します。
    *   `stdout, stderr = bout.Bytes(), berr.Bytes()`: `bytes.Buffer`に蓄積された標準出力と標準エラー出力のデータを、それぞれ`Bytes()`メソッドを使ってバイトスライスとして取得し、`stdout`と`stderr`変数に設定します。
    *   `return`: 結果を返します。

この変更により、`run`関数は大幅に簡潔になり、`os/exec`パッケージの提供する堅牢で高レベルなAPIを活用することで、コードの可読性、保守性、信頼性が向上しました。

## 関連リンク

*   **Go言語 `os/exec` パッケージ公式ドキュメント**: [https://pkg.go.dev/os/exec](https://pkg.go.dev/os/exec)
*   **Go言語 `bytes` パッケージ公式ドキュメント**: [https://pkg.go.dev/bytes](https://pkg.go.dev/bytes)
*   **Go言語 `os` パッケージ公式ドキュメント**: [https://pkg.go.dev/os](https://pkg.go.dev/os) (特に`Pipe`や`StartProcess`について)
*   **Go言語 `io/ioutil` パッケージ公式ドキュメント**: [https://pkg.go.dev/io/ioutil](https://pkg.go.dev/io/ioutil) (Go 1.16以降は非推奨となり、機能は`io`と`os`に分散されていますが、当時のコードを理解する上で参考になります)
*   **Cgoの公式ドキュメント**: [https://go.dev/blog/c-go-is-not-go](https://go.dev/blog/c-go-is-not-go) (Cgoの概要について)

## 参考にした情報源リンク

*   Go言語の公式ドキュメント(上記「関連リンク」に記載)
*   Go言語のソースコード(特に`os/exec`パッケージの実装)
*   Go言語のコミット履歴とコードレビューコメント(`https://golang.org/cl/7450049`)
*   Go言語に関する技術ブログやフォーラム(一般的な`os/exec`の使用方法やベストプラクティスに関する情報)