「Windowsでのターミナル環境」の版間の差分
Notion-MW |
Notion-MW |
||
| (同じ利用者による、間の13版が非表示) | |||
| 22行目: | 22行目: | ||
たとえばテキストファイルに以下のように書いておけば、mpvが起動される。<strong>末尾の半角スペースも入れること。</strong> | たとえばテキストファイルに以下のように書いておけば、mpvが起動される。<strong>末尾の半角スペースも入れること。</strong> | ||
< | <syntaxhighlight lang="vb.net">"C:\Users\username\Softwares\mpv\mpv.exe"</syntaxhighlight> | ||
Windows版のmpvは、設定ファイル（mpv.conf）やプラグインなどを自身が存在するディレクトリから読み込むが、それらの動作を維持したままで、.pathにはmpv.exeという呼び出し専用のファイルだけを配置することができる。 | Windows版のmpvは、設定ファイル（mpv.conf）やプラグインなどを自身が存在するディレクトリから読み込むが、それらの動作を維持したままで、.pathにはmpv.exeという呼び出し専用のファイルだけを配置することができる。 | ||
| 29行目: | 29行目: | ||
<code>myprogram somecommand arg1 arg2 ...</code>と呼び出されたときに、<code>C:\path\to\somecommand arg1 arg2 ...</code>をかわりに実行したい、ということがある。例えば複数の実行ファイルがまとまって提供されるような場合である。このときは以下のようなmycommand.txtをペアにすればよい。この場合はパスを直接引数につなげるため、<strong>末尾に半角スペースを入れてはいけない。</strong> | <code>myprogram somecommand arg1 arg2 ...</code>と呼び出されたときに、<code>C:\path\to\somecommand arg1 arg2 ...</code>をかわりに実行したい、ということがある。例えば複数の実行ファイルがまとまって提供されるような場合である。このときは以下のようなmycommand.txtをペアにすればよい。この場合はパスを直接引数につなげるため、<strong>末尾に半角スペースを入れてはいけない。</strong> | ||
< | <syntaxhighlight lang="python">C:\path\to\</syntaxhighlight> | ||
ところで、<code>C:\path\to\</code>の部分に空白文字が含まれている場合、このままではパスが正しく認識されない。通常はパス全体をダブルクォーテーションで囲うことでこれを回避するが、今回は与えられた引数のどこにダブルクォーテーションを挿入するかが自明ではない（<code>myprogram someprogram"</code>と入力させるという方法もあるが美しくない）ため、<strong>半角スペースを含まない別名</strong>（8.3形式）<strong>を使う</strong>のがよいだろう（短い名前については[[Windowsのパス長さ制限に関して|Windowsのパス長さ制限に関して]]も参照）。例えばProgram Filesなら普通は「PROGRA~1」になっているはずである。以下はGit Bashでのtxtファイルの例である。 | ところで、<code>C:\path\to\</code>の部分に空白文字が含まれている場合、このままではパスが正しく認識されない。通常はパス全体をダブルクォーテーションで囲うことでこれを回避するが、今回は与えられた引数のどこにダブルクォーテーションを挿入するかが自明ではない（<code>myprogram someprogram"</code>と入力させるという方法もあるが美しくない）ため、<strong>半角スペースを含まない別名</strong>（8.3形式）<strong>を使う</strong>のがよいだろう（短い名前については[[Windowsのパス長さ制限に関して|Windowsのパス長さ制限に関して]]も参照）。例えばProgram Filesなら普通は「PROGRA~1」になっているはずである。以下はGit Bashでのtxtファイルの例である。 | ||
< | <syntaxhighlight lang="vb.net">C:\PROGRA~1\Git\usr\bin\</syntaxhighlight> | ||
これにより、PATHを変更せずとも、例えば<code>gb grep</code>などとするだけでGit Bashの<code>grep</code>を呼び出すことができるようになる。gitやnpmやbusyboxやmagick（ImageMagick）のようにサブコマンドを指定して使うプログラムは多くあるが、これと同じような使用感になる。プレフィックスを設けることでそれぞれの名前の集合を別々に管理して衝突を防ぐ、という意味では、多くのプログラム言語で採用されている名前空間（namespace）に近い発想かもしれない。（コマンドにおけるこのような手法に特に名前は付いていないと思う。） | これにより、PATHを変更せずとも、例えば<code>gb grep</code>などとするだけでGit Bashの<code>grep</code>を呼び出すことができるようになる。gitやnpmやbusyboxやmagick（ImageMagick）のようにサブコマンドを指定して使うプログラムは多くあるが、これと同じような使用感になる。プレフィックスを設けることでそれぞれの名前の集合を別々に管理して衝突を防ぐ、という意味では、多くのプログラム言語で採用されている名前空間（namespace）に近い発想かもしれない。（コマンドにおけるこのような手法に特に名前は付いていないと思う。） | ||
| 39行目: | 39行目: | ||
上記と若干似ているが、PATHをはじめとした環境変数を変えることでプログラムがうまく実行されるようにしたい、という場合もある。この場合は、テキストファイルを以下のようにすればよい（Git Bashのフォルダをパスに追加し、<code>MYVAR</code>に<code>value1</code>をセットする例）。末尾の半角スペースはあってもなくてもいい。 | 上記と若干似ているが、PATHをはじめとした環境変数を変えることでプログラムがうまく実行されるようにしたい、という場合もある。この場合は、テキストファイルを以下のようにすればよい（Git Bashのフォルダをパスに追加し、<code>MYVAR</code>に<code>value1</code>をセットする例）。末尾の半角スペースはあってもなくてもいい。 | ||
< | <syntaxhighlight lang="bash">cmd /c path C:\Program Files\Git\usr\bin;%PATH% & set MYVAR=value1 &</syntaxhighlight> | ||
こちらは、先ほどと違って、内部でGit Bashのコマンドを使用する（Git Bashとは無関係な）プログラムを実行する際などに有用である。 | こちらは、先ほどと違って、内部でGit Bashのコマンドを使用する（Git Bashとは無関係な）プログラムを実行する際などに有用である。 | ||
また、これに類似のケースとして、環境変数の設定などを行うバッチファイルが既に用意されていてそれを使いたいという場合もある。例えば以下のようなテキストファイルを用いれば、実質的にVisual Studioの開発者コマンドプロンプト（Developer Command Prompt for VS 2022）の内部で与えられたコマンドを実行してくれるプログラムが作れる。 | また、これに類似のケースとして、環境変数の設定などを行うバッチファイルが既に用意されていてそれを使いたいという場合もある。例えば以下のようなテキストファイルを用いれば、実質的にVisual Studioの開発者コマンドプロンプト（Developer Command Prompt for VS 2022）の内部で与えられたコマンドを実行してくれるプログラムが作れる。 | ||
< | <syntaxhighlight lang="python">cmd /c C:\PROGRA~1\MIB055~1\2022\Community\Common7\Tools\VsDevCmd.bat &</syntaxhighlight> | ||
* ここでも短いパスを使用している。長いパスでも引用符で囲めばある程度うまく動作するが、<code>&</code>の後にくるコマンドに引用符が含まれている場合にうまくいかない。 | |||
Linuxでも、例えば特定のvenv仮想環境の中で与えられたコマンドを実行するシェルスクリプトを全く同じ発想で作ることができる。 | Linuxでも、例えば特定のvenv仮想環境の中で与えられたコマンドを実行するシェルスクリプトを全く同じ発想で作ることができる。 | ||
| 57行目: | 59行目: | ||
上記の例は、いずれもバッチファイルを使って似たようなことが実現できる。例えばGit Bashならそれぞれ | 上記の例は、いずれもバッチファイルを使って似たようなことが実現できる。例えばGit Bashならそれぞれ | ||
< | <syntaxhighlight lang="prolog">@C:\path\to\directory\%*</syntaxhighlight> | ||
や | や | ||
< | <syntaxhighlight lang="vb.net">@cmd /c "path C:\path\to\directory;%PATH% & %*"</syntaxhighlight> | ||
のようにする（<code>@</code>は、echo offを一時的に行うために必要である）。 | のようにする（<code>@</code>は、echo offを一時的に行うために必要である）。 | ||
しかし、cmd.exeには、バッチファイルの実行中にCtrl+Cを送信すると「バッチ ジョブを終了しますか (Y/N)? | しかし、cmd.exeには、バッチファイルの実行中にCtrl+Cを送信すると「バッチ ジョブを終了しますか (Y/N)?」というプロンプトを表示するという厄介な仕様がある。また、<code>%</code>で挟まれた環境変数（<code>%PATH%</code>など）が文字列として含まれていた場合に展開されてしまう。そのため、先ほどの自作プログラムを使用するほうがスマートである。 | ||
<span id="cygwin-msysmingw-git-bashの違い"></span> | <span id="cygwin-msysmingw-git-bashの違い"></span> | ||
| 92行目: | 94行目: | ||
<li><p>詳しくは、「msys2_shell.cmd」を読んでみると良さそうである。MSYSTEM環境変数というのが重要そう。</p></li></ul> | <li><p>詳しくは、「msys2_shell.cmd」を読んでみると良さそうである。MSYSTEM環境変数というのが重要そう。</p></li></ul> | ||
</li> | </li> | ||
<li>[https://m-hiyama.hatenablog.com/entry/20151013/1444704189 Mingw-w64/MSYS2 を入れなくても Git for Windows で間に合うみたい - 檜山正幸のキマイラ飼育記 (はてなBlog)] Git BashはMinGW/MSYSベースなので、そちらと同様に、MSYSTEM環境変数を<code>MINGW64</code>に設定すると/mingw64/ | <li>[https://m-hiyama.hatenablog.com/entry/20151013/1444704189 Mingw-w64/MSYS2 を入れなくても Git for Windows で間に合うみたい - 檜山正幸のキマイラ飼育記 (はてなBlog)] Git BashはMinGW/MSYSベースなので、そちらと同様に、MSYSTEM環境変数を<code>MINGW64</code>に設定すると/mingw64/binがパスに入る。ここにはgit.exeが入っているが、git.exe自体は実は/cmdに入っているので、そのことによる実効的な違いはあまりない。ということらしい。 | ||
<ul> | <ul> | ||
<li>ただgit以外にもxzコマンドとか/mingw64/binにしかないものもいくつかあるので、違いが全くないわけでもない。（なぜxzがこっちに入っているんだろう？）</li> | <li>ただgit以外にもxzコマンドとか/mingw64/binにしかないものもいくつかあるので、違いが全くないわけでもない。（なぜxzがこっちに入っているんだろう？）</li> | ||
| 105行目: | 107行目: | ||
Cygwinでは、実行は問題ないがwhich wtとすると見つからないと言われる（Git Bashでは大丈夫そう）（2023/08時点）。 | Cygwinでは、実行は問題ないがwhich wtとすると見つからないと言われる（Git Bashでは大丈夫そう）（2023/08時点）。 | ||
<span id="cygwinのforkに関するエラーを直す"></span> | |||
== Cygwinのforkに関するエラーを直す == | |||
setupを再実行してバイナリがアップデートされた後に、以下のようなエラーが頻発するようになることがある。毎回出るわけではなく、確率的に生じるので厄介である。 | |||
<syntaxhighlight lang="shell">child -1 – forked process 9272 died unexpectedly, retry 0, exit code 0xC0000142, errno 11</syntaxhighlight> | |||
<syntaxhighlight lang="shell">40 [main] bash 3348 fork: child -1 - forked process 4248 died unexpectedly, retry 0, exit code -1073741819, errno 11</syntaxhighlight> | |||
解決方法はいくつかある（単に再起動などで治る場合もある？）らしいが、自分の場合は以下のようにrebaseallというのをやることで治った。 | |||
[https://stackoverflow.com/questions/9300722/cygwin-error-bash-fork-retry-resource-temporarily-unavailable/14509551#14509551 Cygwin error: "-bash: fork: retry: Resource temporarily unavailable" - Stack Overflow]（元記事は[https://cygwin.fandom.com/wiki/Rebaseall https://cygwin.fandom.com/wiki/Rebaseall]らしい） | |||
ここには<code>rebaseall -v</code>と書いてあるが、手元ではそのようなオプションがなさそうだったので単純にrebaseallとしたら、それでうまく行ったようである。 | |||
<ul> | |||
<li><p>まとめると、手順は以下。</p> | |||
<ul> | |||
<li>Cygwin関連のプロセスをすべて終了させる。</li> | |||
<li>/usr/binにある<strong>dash.exe</strong>を<strong>管理者権限で</strong>起動させる（おそらく軽量で依存関係が少ないから？）</li> | |||
<li><code>./rebaseall</code>を実行</li></ul> | |||
</li> | |||
<li><p>他には以下のようにWindowsのセキュリティ設定をいじる方法もあるようだが、ちょっと不安。</p> | |||
<p>[https://oni-gili.org/archives/290 https://oni-gili.org/archives/290]</p> | |||
<p>[https://umateku.com/archives/462 https://umateku.com/archives/462]</p></li></ul> | |||
<span id="cygwinでcmdにを出力させる"></span> | <span id="cygwinでcmdにを出力させる"></span> | ||
| 158行目: | 184行目: | ||
フォントは、GUIからではなく設定ファイルを変更する必要はあるが、変えられる。デフォルトのCascadia CodeよりConsolasのほうが英数字が日本語のちょうど半分のサイズになるので読みやすい。 | フォントは、GUIからではなく設定ファイルを変更する必要はあるが、変えられる。デフォルトのCascadia CodeよりConsolasのほうが英数字が日本語のちょうど半分のサイズになるので読みやすい。 | ||
< | <syntaxhighlight style="margin-bottom:0.2em;" lang="vb.net">"defaults": { | ||
"font":{ "face": "Consolas", | |||
"size": 12 | |||
} | } | ||
},</ | },</syntaxhighlight> | ||
<div style='text-align: center;'>設定例</div> | <div style='text-align: center;'>設定例</div> | ||