Zenn
🐡

おれのubuntu(WSL2)設定メモ

2024/08/11に公開
WSL 2
tech

はじめに

Ubuntu(WSL2)は、

Hyper-VのVMでの動作ではあるが、純粋なLinuxカーネル上で、Ubuntuのディストロを動作させて
Windowsとの統合がなされて、作業のしやすい環境です。

Linuxをターゲットとしたアプリの開発環境としては、非常に有効な

環境ではないかと思っています。

なので、とても、気に入っています。

まずは、

★★ 右側のサイドバーの目次のメニュー項目をざぁっと、ながめてほしいです。 ★★

大枠、どのような事が書いてるかというと

まずは、
WSL2で作業時の基礎的な考え方を書いてます。

それから、

dockerを使った時にMacユーザとの環境差より生じる
バインドマウンドしたホスト側での作業時に発生する★権限問題★を
★★ 「一発で驚くほど楽に解決できる」ついて記載があります。　 ★★
★★ 「一度、設定してしまえば、後はなにもしなくてもよくなります」　★★
★★ 頻繁に「sudo chown -R myuser:mygroup .」を実行するなどの、めんどい事は不要　★★

★★ それは、POSIX ACLという枯れた信頼性の高い技術を使う方法です　★★

これでもう、dockerでバインドマウント時の★権限問題★に、さよなら、できます。

新しい環境を作ったときに、当サイトのPOSIX ACLにあるコマンドを
メモ帳などにコピペして編集し、それらのコマンドを1回打ち込んで設定することを、
やればいいだけです。それだけです。それだけで、

dockerでバインドマウント時の★権限問題★に、さよなら、できます。

補足:
「dockerを使った時にMacユーザとの環境差より生じる」と書いたが
ターゲットをLinuxとしたアプリ開発での開発環境であれば、
ネイティブLinuxや、Ubuntu(WSL2)での環境を考慮した
docker設定や手順こそが本来的で、そちらにあわせていれば
Ubuntu(WSL2)側としては、そもそも、なんの問題もおきないのである。
MacはBSD系のUnixのためLinuxではありません。
そのBSD系のUnixであるがゆえに特有の環境だがMacユーザには楽なdocker設定を
現状多数派であるという理由で、チーム内で連携してくるから
Ubuntu(WSL2)側で★権限問題★が発生するだけです。
Linuxをターゲットにしてるなら、Linuxカーネルを使ってる
Ubuntu(WSL2)側に、むしろ、あわせろよ。と思うんだけど。
仕方がないので調べた結果
POSIX ACLの解決策が最も楽であるとの調査結果に至ったのです
このあたりの話は「上記で最後で記載した★権限問題★とは何か」
の項目の後半で詳細に説明しています。

また、

Xdebugなどdocker-compose.ymlでの追記、箇所
dockerを使った場合に焦点あてて書いてます
その他、Laravelでの開発者向けに、ide-helperについて記載してます。

他、
Linux版のGitkrakenのインストール方法や、考え方を記載してます。
( Ubuntu領域にある大規模gitリポジトリの場合、sourcetreeが固まって使えない問題で、
sourcetreeに代わりとして使えるものとしてのLinux版のGitkraken )

他、もろもろ

＜＜今後も、都度、必要な情報、有効な情報を追記して充実させたいと思ってます＞＞

このような情報を充実させて、
Ubuntu(WSL2)の環境でのエンジニアを増やしたい。
と思ってます。
Ubuntu(WSL2)の環境を利用する敷居を低くすることに貢献したい

当サイトを書いてる目的

目的は、２つあります。

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
★ ＜1つ目の目的＞ ★
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
Ubuntu(WSL2)の環境でのエンジニアを増やしたい。
増えれば、増えるほど、インターネット上に情報が増えて
トラブルシューティングがしやすい状況となる。
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

それから、

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
★ ＜2つ目の目的＞ ★
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
私自身が自分のためのカンニングペーパーになるサイトが欲しい
時間かけて過去に調べた情報を必要な時に、すぐに、引っぱり出せる
カンニングペーパーが欲しい
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

＜2つ目の目的＞だけであれば、自分がわかる程度の箇条書きや、簡素な書き方でよいのですが
＜1つ目の目的＞の動機があるため、かなり文章を書きました。

すいません、
日本語の文字列への項目へのページ内リンクがzennのmarkdown記法で、
サポートがないみたいで、ページ内リンクが作れませんでした。
右のサイドバーの目次のメニューや、Ctrl+Fでの文字列検索を活用してほしいです

想定読者

Linuxの基礎知識がある人で、
Ubuntu(WSL2)でのdocker環境での開発での困りごと解決やその手の知識を拾っていきたい人
などを想定してます。
すいませんが、Linuxの基礎知識は前提にさせてもらいます。
その前提もなしにしてしまうと記述量が膨大になってしまいます。

最初からWindows Terminalでの作業がオススメ

「Windows Terminal」だと既存のPowershellも使えます。
複数タブで切り替えて作業しやすいです。
それから、見た目のデザインもかっこいいです。

後述の、
目次の項目の「Windows Terminalが作業しやすい」を先に見て、
wsl -l -oなどや、UbuntuのディストロのインストールからWindows Terminalで
作業してもよいぐらいだと思うです。

なお、WindowsでWSL2自体を有効にする方法などは
https://lazesoftware.com/ja/blog/230130/
のサイトなど、他でもネットにあります。
Docker Desktop自体のインストールなどもネット上に既に情報がありますので
当サイトでは、そこらへんの記述は割愛します。
その後、どうするかなどについての記述にします。

ちなみに、Windows版のDocker Desktopのインストール方法はこちらに情報ありました。
https://zenn.dev/longbridge/articles/d9f544f5b4cb82

Windowsとの統合の話

ls -l で表示されるようなファイルやディレクトリの所有者やパーミッションなどの
概念はそもそも、Windowsにはありません。

にもかかわらず、
Windowsのエクスプローラーや、Windowsのアプリで
Ubuntu領域のフォルダに対して、
\\wsl.localhost\Ubuntu-24.04-my\　からはじまるようなWindows用のパスで
アクセスできます。
そのまま、その場所に、ファイルや、フォルダを作れてしまいます。
そのとき、Ubuntu側のターミナルで、作られたファイルや、フォルダを
ls -lで見た時に所有者やパーミッションはどうなるのだろうか？
Windowsには、ls -lで見た時に所有者やパーミッションなどの概念ないが
この場合は、どうなるんだろうか？

そんなところが、最初、疑問でした。

Ubuntuのディストロをインストール時に、作る初期ユーザ―での実行として
作られたファイルや、フォルダは、そのユーザーの所有物となるような
連携がWSL2の仕組みにあります。
WindowsのアプリでUbuntuの領域で操作時は、その仕組みで
Ubuntu側での初期ユーザ―での実行されたことになる連携のようです。

ちなみに、その初期ユーザはユーザ名とグループ名は同じ文字列で
UID=1000、GID=1000で、インストールしたディストロに作られます。

そういう情報を見て、実際にWindowsアプリでUbuntuの領域にファイルを作ってみたら
所有者が初期ユーザとなってるのを確認できた。
パーミンションはデフォルトのumaskが効いてる感じなのか、
フォルダは755、ファイルは644になってました。

それから、その初期ユーザでは権限がない操作は、Windowsのアプリを通じても
Ubuntu領域ではできないようになってました。
エラーメッセージで怒られるか、単に、怒られないが無視されて実際にはできないなど
Ubuntu側のターミナルでsudoを通じてなどで権限調整をするコマンドを打ち込んでから
Windowsのアプリを通じてやってみたらできました。

つまり、

Ubuntuの領域に対して、実行ユーザが初期ユーザ―として
Windows側の機能で操作できる状況になっていることを理解しました。

上記のような体験を通じて納得していった覚えがあります。

それから、Ubuntuの環境変数PATHの後ろのほうに、WindowsのアプリへのPATHの値が
自動的に追加されていた。
Ubuntuのターミナルから、Windows側のプログラムや、アプリやデータにアクセスしやすいような状況になってます。

code . でカレントディレクトリでVisualStudioCodeが起動できたり、
explorer.exe . でカレントディレクトリについて、エクスプローラーを起動したり
そういったことができるのも、環境変数のPATHの末尾にWindows側の値が
追加されているからです。

WSL2では共通のLinuxカーネルが動いてます。
その共通のLinuxカーネルで、インストールした各ディストロ(ディストリビューション)や、
Docker Desktopをインストールした場合は、そのDockerが動きます。

それらの各、ディストロのUbuntuなどに対して、
上記のようなWindowsとの統合がなされてる環境だと理解しました。

Windowsの機能をある程度、活用しながら作業ができるLinux環境のようなものです。

しかも、WSL2からはHyper-VのVMではあるが、純粋なLinuxカーネルとのこと。

純粋なLinuxカーネルと言っても、Windowsとの統合のために若干は手を加えられて
いるような感じなのか・・。

すいませんが、そこまでの詳細は私にはわかりません。

ただし、純粋なLinuxカーネル上で、Ubuntuなどのディストロを動作させて
Windowsとの統合での作業のしやすさがあれば、
Linuxをターゲットとしたアプリの開発環境としては、非常に有効な環境ではないか
と思っています。

なので、とても、気に入っています。

このUbuntu(WSL2)での環境のアプリ開発者が、もっと、もっと増えて
インターネット上に、沢山情報が書き込まれて、
トラブルシューティングがしやすい状況にどんどんなっていけいいなぁ
と思ってます。

そんな人が、どんどん増えてほしいです。

だから、私も当サイトのような記事を書いてます。

私自身が自分のためのカンニングペーパーになるサイトが欲しかったというのもあります。
時間かけて過去に調べた情報を必要な時に、すぐに、引っぱり出せる
カンニングペーパーが欲しいということです。

上記で説明したWindowsとの統合の、考え方が最初、わかりませんでした
やりながら、あぁ、なるほどと、納得していった記憶があります。

最初にその考え方がわかったほうが、やっていきやすいだろうと思いました。

だから、一旦、考え方の説明文をここに書くことにしました。
ここに書いた文章を読むだけで、やったことが無い人でも
ある程度はイメージが付くのではないか
イメージが先についたほうが行動しやすいと思います。

上記の話を前提として、ここからは注意点を書きます。

普通に、インストールしたディストロをそのまま使ってる場合は、
上記のようなWindowsとの統合が、何もしなくてもデフォルトで効いてくれてるので、
気にしなくてもいいです。

しかし、もし、
ディストロを別名でimportして複製した場合は( 私の場合は、そうしてるのですが )
上記のような、Windowsとの連携が外れた状態になってしまいます。
その場合は、wsl.confの記述をして、上記のようなWindowsとの連携が効くようにする
必要があります。
その件については、それが必要な人は、
目次の項目の「ディストロのexport／importなど」の項目を読んでもらった後に、
目次の項目の「wsl.confの設定変更時の参考ネタ」の項目を読んでもらえば
よろしいかと思います。

dockerを使う開発ではUbuntu(WSL2)を使うのがよい

https://lazesoftware.com/ja/blog/230130/
のサイトで、dockerコンテナより、バインドマウントするホスト側が
NTFSファイルシステムだと変換処理のため非常に動作が遅い
言及されてる解決策２より、ホスト側は、Ubuntuを使うのがよい

補足:
別にdockerを使う、使わないに限らず、
そもそも、Linuxをターゲットにしてるアプリの開発であれば
Ubuntu(WSL2)を使うのがよいと思います。
Windows直で開発環境を作るより、Ubuntu(WSL2)に開発環境を作ったほうがよいと思います
環境的にWindowsだと対応してないものもあると思います。
Linuxをターゲットにしてるアプリの開発で、Ubuntu(WSL2)の環境で対応してないことが
あるとはあんまり思えないです。また、チーム内でのMacユーザの環境構築の方法との
親和性を考えた時、Windowsに環境構築するより、
Ubuntu(WSL2)に開発環境を作ったほうが有利ではないかと思います。
上記のサイトの解決策2では、dockerでバインドマウントした時に、
NTFSファイルシステムへのバインドマウントだと
遅いということを回避したいという動機で、Ubuntuを使うことが書かれていますが、
そもそも、Linuxをターゲットにしてるアプリの開発であれば、
dockerを使う、使わないに限らず、Ubuntu(WSL2)を使うのがよいと思います。

ただし、Ubuntuを使っても/mnt/cなどからはじまるWindowsのNTFSをマウントしてるところ
だと意味がない
ちゃんと、それ以外のlinuxのパスでのホスト側のext4ファイルシステムの領域を
バインドマウントしなければ意味がないです。
ただし、この方法を使うと★権限問題★が発生する。
それは、すぐ、下の
目次の項目の「上記で最後で記載した★権限問題★とは何か」
の項目を読んでいただければよいと思います。
その★権限問題★が何かの説明が詳細に書かれています。
( 理解しようとするとLinuxの基礎知識や、dockerの概念が必要になります )
( 理解できなくても、とりあえず、対処法のPOSIX ACLだけやっといて回避しとくのもよい )
そして、その解決方法として当サイトでは、POSIX ACLをおススメしているので
★権限問題★の対処法については、目次の項目の「POSIX ACL」の項目を読んでいただければ
よろしいかと思います。

補足:
個人的には、ホスト側の 「/home/ユーザー名」の配下のフォルダを
バインドマウントの対象とするのは、あまり、おススメしない。
理由は、dockerコンテナ側にユーザーを作りたくなった時に、
詳細は忘れたがうまく動かない要因があり、環境を作り直したことがあった。
なので、ホスト側の/の直下に、sudoなどでroot権限でフォルダを作って
それを「sudo chown -R myuser:mygroup /そのフォルダ名」
で、作業ユーザーの所有者に変更後、その配下に作業ユーザで作っていった
ホスト側のフォルダをバインドマウントの対象にしておくようにしている。
dockerコンテナ側にユーザーを作りたくなることがあるのか？
という話ですが、それは開発作業中に、実装したいものの仕様によっては動作確認のため
あるかもしれない、そんなのはわからない。
けれど、そうなっても問題がないやり方に、はじめからしとけばよいと思います。

上記で最後で記載した★権限問題★とは何か

Mac環境ではおきないが、Ubuntu環境ではおきる権限問題がある

  • dockerコンテナ内部はrootで作業する(普通はそうであるとのこと)

補足:
rootで作業する(普通はそうであるとのこと)
と書いたが本当はそうは思わない。
実際にはBSDのUNIXなのに、Linuxだと嘘ついての多数派である
Macユーザの作業が楽だから、そうしてるだけの話で、
そんなのは、全く、本来的ではないはず。
仕方がないから、こちらがそれに同調して、「(普通はそうであるとのこと)」
と言ってあげてるだけの話。
後述の本来的な話としては、システム作業はrootで、それ以外は一般ユーザと
分けて使うのが本来のはず。

  • ホスト側は一般ユーザで作業する

  • ディレクトリや、ファイルを作成した時の所有者は作業した実行ユーザー

  • dockerコンテナ側のrootで作業中に作られたものはroot所有

  • ホスト側の一般ユーザで作業したものは、一般ユーザ所有

  • しかし、Macでは、バインドマウントしている領域はホスト側で見た時は、常に一般ユーザ所有になってる。

    そのためMacでのホスト側で一般ユーザで実行するgit操作などでは権限エラーなどの
    問題がおきない。
    (同一ファイルやディレクトリについてdockerコンテナ側がroot所有であっても)

    なぜ、そうなるかの理由は複雑であるため、後述の

    ＜＜なぜ、Mac環境では、この権限問題がおきなくてUbuntuではおきるのか＞＞
    のところで、説明を詳細に書いてますので、そこを参照してください。

    一方、
    Ubuntuではdockerコンテナでroot所有になったものはホスト側でも
    root所有となるため、ホスト側での一般ユーザでのgit操作やその他の作業時に
    root所有となってるファイルや、ディレクトリが混在しているがために権限エラーの
    トラブルとなってしまう。
    Dockerfileをローカルで編集するなどして、ホスト側で作業する一般ユーザーと
    UID、GIDをあわせたユーザを作り、dockerコンテナ側の作業もそのユーザにあわせる
    などの考え方もあるが

    補足:
    そもそも、この考え方が本来的であろう、Linux/Unixでの作業なのだから
    rootユーザでシステム構築して、他は一般ユーザで作業し、ネットワーク越しなら
    両サイドでUID、GIDを合わせた同一ユーザで作業する考えなどは
    Unix系では基礎的な考え方であり、それを無視して単にMacで楽ができる方式
    で連携してくるのでUbuntu(WSL2)側で★権限問題★がおきてしまうのである

    仕方がないので、調査した結果、
    POSIX ACLを使う解決策がありまして、それが最も楽な( この本来的でない状況での )
    解決法だったので、このサイトでは、おススメとして紹介してる次第である。
    ここでは一旦、この権限関連の問題点の説明を続行する。

  • Ubuntu側は、バインドマウント領域は一般ユーザ所有とroot所有が混在した状態になる

  • バインドマウントした領域は通常は、gitのローカルリポジトリのルートディレクトリなど

  • Ubuntu側で、ブランチ切替や、プル時に権限エラーなどがでてgitが不整合になってしまう

  • gitコマンドは一般ユーザで打ち込むため、root所有のディレクトリでファイルを作成、削除などは権限エラーでできない。root所有のファイルを更新、削除などできない

  • ステージング追加、削除や、commitは実ファイルの操作でなくgit内の管理領域の更新なので、この手のエラーはでない。git checkoutや、git pullなど実際にディレクトリ、ファイルを作成、更新、削除する行為の時に問題が発生する

上記、問題の解決策については、このサイトの

POSIX ACL

で説明している解決策がおススメ

ローカルのgitリポジトリのルートディレクトリを基点に配下の末端までに対して

POSIX ACLで作業している一般ユーザにフル制御の権限を別枠でカーネルレベルで

付与する方法である。

POSIX ACLは、20年ぐらい前からある枯れた技術のようなので信頼性は高いだろう


★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
＜＜なぜ、Mac環境では、この権限問題がおきなくてUbuntuではおきるのか＞＞
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
ところで、ここで話題になってる権限問題は、

なぜ、Macでは発生しないが、Ubuntu(WSL2)では発生するのかを説明する
かなり複雑な話なので、順を追って説明するしかありません。
そもそも、dockerはLinuxカーネルで動くものである
DockerHubのイメージは何かのLinuxのディストリビューションのみで
そこにレイヤーを重ねていく方式となってる
ホストマシンにLinuxカーネルがなければ、dockerは動作しない
MacはUnix系であるがBSD系のUnixがカーネルであり、直接、dockerを動作させることができない

そのため、hyperkitなどのVMでlinuxカーネルを準備して、そこでdockerを動作させている
(詳細は知らんしMacの種類や環境で異なるのか？、そこらへん知らんけど、とにかくVMで)

つまり、Mac本体とdockerは別カーネルで、別々にうごいており
バインドマウントは、別々に動いてるもの同士をくっつけるようなことを
する必要性が、Macでdockerを使う場合はある。

それに、
Macはファイルシステムもaplfsなどで、linuxのext4とも異なる

カーネルだけでなくファイルシステムも異なるため、dockerコンテナからホストへ
バインドマウント時に直接的なマウントできない

そのため、osxfs, Fuse, virtioFSなどの共有ファイルのやり方を間に介して
バインドマウントする


そのため、Ubuntu(WSL2)でのバインドマウントよりも低速である
もっとも、virtioFSが使えるようになってから、かなり速度改善があったようではあるが・・


これらの、osxfs, Fuse, virtioFSなどの共有ファイルの仕組みは、
「こちら側」と「あちらが側」で権限に２面性がある様子。
わかりにく話かもしれませんが、すぐ後で、俗っぽい言葉で説明しなおしてますので
一旦、我慢して読んでください。

つまり、
ファイルや、ディレクトリに付与される
所有者ユーザー、所有グループ、パーミンションが
dockerコンテナ側と、ホスト側で異なる状態になりうるようである。


Macのdockerのバインドマウントについて、
このあたりの影響してなのか、それが意図して設計した動きとしてそうなったのか、
偶然にも図らずもそうなったのかは不明だが
dockerコンテナ側でroot所有であっても、バインドマウントした領域で
同じディレクトリや、ファイルをホスト側で見た時に、一般ユーザの所有となっている
ホスト側で見た時に、一般ユーザの所有となっているので、
前述のgit操作でのブランチ切替や、git pull時での
権限エラーの問題が発生しないのである。

★★★★★★★★
わかりにくい事柄なので、俗っぽい言葉で説明をしなおします。
★★★★★★★★
例えばの話、PC上のある領域を他の人にも見えるように共有したとします。
自分は読み書きできる状態だが、他の人は読み取り専用の設定などしたとする。
その場合、共有したときに、「こちら側」と「あちら側」では権限が異なります。
この例の場合、
「こちら側」：自分は読み書きできる
「あちら側」：他の人は読み取り専用
という権限の２面性のこと。
ですので、共有ファイルやら、そういった仕組みは、そもそも、
「こちら側」、「あちら側」など本来的に、権限に2面性を持ったものであり、
osxfs, FUSE, virtioFSも、そのようなものではないか。
そんなosxfs, FUSE, virtioFSを間に介して、Macがdockerのバインドマウント
を解決しているので、
dockerコンテナ側はroot所有だが、同じファイルや、ディレクトリについて、
ホスト側では、一般ユーザー( おそらく、dockerコンテナを起動したユーザー )
の所有となるの２面性を持った権限状態になってるのではないか
ということを説明したかった。( 説明するの、めんどい話ですけど・・ )
それが、意図してそれを設計した結果そうなったのか、偶然にも図らずも、そうなったかは
知らないが、実際問題、Macユーザはこの話題での権限問題で、
git操作時、ブランチ切替や、プルでエラーになったりしないとのこと
★★★★★★★★
それで、
この詳細を知ってか知らずか、Macで問題がおきなかったのだからと
そのようなdocker-compose.yml, Dockerfileがチーム開発で提供されることがある
その時に、Ubuntu(WSL2)利用者としてはどう対処すべきかである
その解決策として当サイトでは、後述にてPOSIX ACLを使うのがよいのではないかと説明してる。


一方、


Ubuntu(WSL2)では、WSL2での共通のLinuxカーネルにてdockerおよび、Ubuntuのディストロが動作している。
dockerコンテナは技術的には、linux上のnamaespaceで隔離された単なるプロセスに過ぎない
したがってバインドマウントしても、それは同じlinuxカーネルで動いてる別プロセスが
namespace違いを解決した形で単にアクセスしているだけである
そのため、Ubuntu(WSL2)での(というかネイティブlinuxでも多分、そうだが)
dockerコンテナからホストへのバインドマウントは最も高速である
バインドマウントについて、速度面については気にする必要はない
ただし、dockerコンテナでrootで作業し、root所有として作成されたものは
ホスト側で見てもroot所有となっているため
そのままでは、ホスト側の一般ユーザで操作しようとした時に権限エラーとなってしまう
だからといって、毎回、毎回、頻繁に
sudo chown -R myuser:mygroup .
をgitリポジトリのルートディレクトリで打ち込んで回避するやり方もめんどいし
やり忘れてgit操作してしまい、エラーでgitが不整合になるとそれを直したりする作業が
煩雑でめんどいので、一回、設定しとけば後は何もしなくても問題なしとなるような
解決策が望まれた。その解決策として後述のPOSIX ACLを書いてるのである。
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★


以上、本当に説明するのが、非常にめんどい、話だったのですが
なんで、こんなことになってるのかということです。
それは、昔、WSL2の環境がなかったときに、Linuxをターゲットにしたアプリの開発では
UnixがベースになってるMacで開発環境を作ったほうが圧倒的に有利だったわけです
その歴史的な背景で現状、Macユーザが多いため、Macユーザ側で作業が楽なやり方での
環境構築の連携がされがちなところが、あるのではないかと思うです

でも、よく考えてみれば、MacもUnixベースではあるがベースとなってるのは
BSD系のUnixであるため、Linuxではないんですね
だから、virtioFSを介した結果での上記ような事などになってるんだと思うんです。

よく考えてもらいたいのですが、
Ubuntu(WSL2)でLinuxベースの環境のほうがLinuxアプリの開発環境としては
より本来的なのではないかと、個人的に思うです

だから、もっと、Ubuntu(WSL2)でのLinuxターゲットのアプリ開発者が増えてくれて
人数比で負けない状況となれば、あとは、理屈の本筋論、
本来は、どっちが本筋なのか？　Linuxカーネルでしてるほうでしょ
と、言い返すことができると思うです

そしたら、Ubuntu(WSL2)利用者にとっての状況が改善するんじゃないかと思うです
そのために、Ubuntu(WSL2)利用者を増やしたい

私の、このサイトも、Ubuntu(WSL2)利用者を増やす助けになれば幸いだと思うです。



dockerの基礎知識

dockerの基礎知識は、

https://zenn.dev/suzuki_hoge/books/2022-03-docker-practice-8ae36c33424b59

のzennの本を全部読んだら概念がわかりやすい
でも、dockerのコマンドを一個一個、覚えて打ち込んでいく方法は難しいので

上記で基礎概念を見た後に

docker-composeを使った方式が手早い

機会があれば、docker-compose.ymlなどについても当サイトに追記したい

kubernetesというのがあるらしいが、そこまでの発展系は、私には、まだ、よくわからない



Windows Terminalが作業しやすい

Microsoft StoreからインストールできるWindows Terminalが作業しやすい

インストール後は、スタートメニューの横の虫眼鏡で、terminal 打ち込んだから

カタカナで、「ターミナル」という項目が出てくるので、それを押すと
Windows Terminalが起動できる

複数のディストリビューションとか、普通にpowershellや、コマンドプロンプトとか、タブで切り替えて使える。

wsl -d ディストリビューション名

例)
wsl -d Ubuntu-24.04-my

補足:
このコマンドは、powershellで実行します。
windows terminalは、起動時のデフォルトは、powershellです。
wslコマンドで、ディストロにログインします。
exitで出たら、また、powershellに戻ります。

上記コマンドで、対象のディストリビューションを選択してログインできる。
なのですが、毎回、
wsl -d ディストリビューション名
を打ち込むのは、めんどいので、
いつも、使うディストロが決まっているのであれば
wslと打ち込むだけで、そのディストロにログインできるようにしておきたい

そんなときは、

wsl --set-default <ディストリビューション名>

例)
wsl --set-default Ubuntu-24.04-my

補足:
このコマンドは、powershellで実行します。
windows terminalは、起動時のデフォルトは、powershellです。

で、デフォルトのディストロを設定できる。
wslとだけ打ち込んだときは、デフォルトのディストロにログインすることになる。

wsl -l -v

補足:
このコマンドは、powershellで実行します。
windows terminalは、起動時のデフォルトは、powershellです。

で現在、環境にあるディストロのリストが見れるがデフォルト指定したディストロには、

「*」記号がが付いて表示される。

また、
今どのディストロにログインしているのかわかりにくくなったら

wslpath -w .

を実行して確認している。
このコマンドはWindows用のパスに変換して表示するためのコマンドであるが
そのときのWindows用のパスは、その一部にディストロ名があるため
そのディストロ名を見れば、今、どのディストロにログインしているのかを
確認することができる。

例として
$ pwd
/etc/systemd
のとき

$ wslpath -w .
\\wsl.localhost\Ubuntu-24.04-my\etc\systemd

この\wsl.localhost\Ubuntu-24.04-myの部分を見て

Ubuntu-24.04-myのディストロにログイン中かと確認できる。

この、wslpath -w . は、カレントディレクトリについて

Windowsアプリが参照できるパスの形を返す。

エクスプローラーに貼り付けるような使い方もありかもしれないが

そもそも、カレントディレクトリについてエクスプローラーで開きたかったら

explorer.exe .

と打ち込めば、カレントディレクトリについてWindows用のパスで、
explorerが起動する。
私は、どうしても、explorerのスペルが覚えられない。
普通に打ち込んだらスペルミスをしてしまう。
( .exeまで必要であることなども、わかりにく、他のコマンドはそんなことないのに、
こいつだけイレギュラーで、そんなの覚えられない )
でも、大丈夫、
explまで打ち込んでタブを押せば
explorer.exeおよび、スペースまで入力補完されるので、後は.を後は打ち込んで
Enterキーを押せばよい。
むしろ、expl+TAB+.+ENTERで
「イーエックスピーエル、タブ、ポチ、エンター」の呪文ほうが
explorer.exeのスペルより覚えやすいとさえ、思っている。
( 完全に、私の特有の感覚の話ですけど )





ディストロのインストール

wsl -l -o

補足:
このコマンドは、powershellで実行します。
windows terminalは、起動時のデフォルトは、powershellです。

でインストール可能なディストロの一覧を表示する。

LTSが付いてるもので一番、バージョンが高いものをインストールすればよいと思うです。

wsl --install -d <ディストリビューション名>

例)
wsl --install -d Ubuntu-24.04

補足:
このコマンドは、powershellで実行します。
windows terminalは、起動時のデフォルトは、powershellです。

で、「wsl -l -o」のリストより、対象のディストロ指定してをインストールできます

インストール時に、初期ユーザ名とパスワードを入力する

この初期ユーザは、ユーザー名、グループ名が同じで

UID、GIDがともに1000で作成されたりする

WindowsのアプリからUbuntuの領域にファイルやフォルダを作成された時

この初期ユーザでの実行とみなされ、作られたファイルや、フォルダの所有者も

Ubuntu上では、この初期ユーザとなる。

上記のように、インストールしたディストロを直で使ってもよいが

個人的には、それはそのまま置いておいて、そこから別名で複製したものを

使うようにしてる。

一旦、exportしてimportするときにしか別名はつけられない



ディストロのexport／importなど

「Ubuntu-24.04」から「Ubuntu-24.04-my」を複製するケース
export/importしないと直接、ディストロの名前を、好きな名前に変更できない

補足:
powershellで実行します。
windows terminalは、起動時のデフォルトは、powershellです。

エクスポートの例

wsl --export Ubuntu-24.04 Ubuntu-24.04.tar

インポートの例

wsl --import Ubuntu-24.04-my C:\MyWSL\Ubuntu-24.04-my Ubuntu-24.04.tar

この「C:\MyWSL\Ubuntu-24.04-my」は自分であらかじめ、そういうフォルダを準備し
指定します。わかりやすいフォルダ構成がよいでしょう

インポートすると、そこにHyper-Vの仮想マシンを表すファイルができてます。

消す場合の例

wsl --unregister Ubuntu-24.04-my

★これやると本当に消えてなくなってしまうから、慎重に！★
これを実行するとHyper-Vの仮想マシンを表すファイルが綺麗に消えてなくなってます。



wsl.confの設定変更時の参考ネタ

普通にインストールしたディストロをそのまま使ってる時はあまり気にしなくてもよい

その場合はWindowsが管理しているシステム系の深いフォルダ階層にHyper-Vの仮想マシンファイルがおいてあるなどする

また、wsl.confを特にいじらなくてもWindowsのNTFS領域を勝手にマウントしたり

ターミナル上で初期ユーザ―(インストール時)でログインしたりの設定になっていたりする

ただし、

*.tarファイルにexportして、importするときに、ディストロの名前を
Ubuntu-24.04からUbuntu-24.04-my
などに、名前を変更したようなディストロを使う時、
下記のようなwsl.confにしてないと、具合が悪かった
要するにwsl.confに設定を書いておかないと
WindowsのNTFS領域を勝手にマウントしたり

ターミナル上で初期ユーザ―(インストール時)でログインしたりの設定になってくれない

環境変数のPATHにWindowsのPATHの値を追加してくれるかどうかも、おそらくあやしかった

詳細は忘れてしまったが、それらを回避するため、wsl.confの設定を変更する必要があった

その件についてのメモ書き

例として
\\wsl.localhost\Ubuntu-24.04-my\etc
の
wsl.conf
を下記のようにしとく

myuserのところだけ、自分のユーザ名にしておく
Ubuntuをインストール時に初期ユーザがUID=1000、GID=1000で作られてたりするので
それを指定するようなイメージ

[boot]
systemd=true

[automount]
enabled=true
root = /mnt/
options="metadata,uid=1000,gid=1000,umask=002,dmask=002,fmask=002"

[user]
default=myuser

[interop]
appendWindowsPath = true

の記述内容にして

wsl --shutdown

補足:
このコマンドは、powershellで実行します。
windows terminalは、起動時のデフォルトは、powershellです。

を実行し、設定を反映する






新しいディストロ使いはじめるときdockerが使いたければ

新しいディストロ使いはじめるとき、そのディストロでdockerが使いたい場合は、
https://lazesoftware.com/ja/blog/230130/
のサイトで説明しているように、Docker Desktopの画面で、

設定の歯車マーク
↓
Resouce
↓
WSL Integration
で、
そのディストロを有効にして

そのディストロでDocker Desktopが効いて
dockerが使える設定にしておくことを忘れずにしておこう。


それから、当然のことながら
設定の歯車マーク
↓
General
で、
Use the WSL 2 based engine
にチェックが入ってる必要はあります。



新しいディストロ使いはじめるときなどに最新化しとく

新しいディストロ使いはじめるとき

sudo apt update
sudo apt upgrade

は、最初に、一度は、やっておいたほうがよさそう
新しいディストロ使いはじめるときなどにやっとく
新しいPC買ったら、更新して最新化すると思うが、そのイメージ

そのほうが後々に、作業時に環境トラブルになりにくいのではないか。



WSL-RemoteでVisualStudioCodeを動作させる件の話

VisualStudioCodeで作業フォルダとして開きたいディレクトリ
( たとえば、.gitフォルダがおいてるローカルのgitリポジトリのルートディレクトリ
などそこがソースコードが置いてる場所のルートディレクトリだったりするディレクトリ )
がカレントディレクトリの状況にて

code .

を打ち込んでVisualStudioCodeを起動する
VisualStudioCodeで、
Remote Development
のプラグインをインストールすると、このプラグインはパックになっているので、
WSL
Dev Container
Remote - SSH
Remote - Tunnels
などのプラグインもインストールされる。
それから、自分が今、VisualStudioCodeにインストールしている
他のプラグインも一通り見ていくと
「Ubuntu XXXXXにもインストール」みたいな青色のボタンが表示されているものが
あったりする。
※ Ubuntu XXXXXは、今操作してるディストロ名のことです。
それらは、ひとおおり、そのボタンを押して言って
今操作しているディストロでVisualStudioCodeを起動時に有効になるようにしていく
その後、
一旦、VisualStudioCodeを閉じて、
再度、

code .

で起動する
メニューで「表示」－「ターミナル」でVisualStudioCode上でターミナルを表示できるが
pwdで表示したパスが、
\\wsl.localhost\Ubuntu-24.04-my\ などからWindows用のパスでなく
/からはじまるLinux用のパスであること
や、
whoamiで、自分のユーザーを引き継いでるかとか
必要な環境変数などを引き継いでるかなど確認し
OKそうであれば、
WSL-RemoteでのVisualStudioCodeの起動ができてると思われる
これは何かというと、説明がめんどいのであるが
VisualStudioCode自体は、Windowsアプリであるが
Linuxを意識して、それで直で動くLinuxアプリのような動きをして
WindowsとLinuxの変換が発生しないような動き方で、動くことができてる
設定になってるかというような意味だと思われます。
厳密な意味は若干、間違ってるかもしれませんが、だいたい、そんな感じでしょう。



VisualStudioCodeの拡張プラグインの調子が悪いとき

~/.vscode-server
自体を削除する

cd ~
mv .vscode-server .vscode-server_backupYYYYMMDD

などでバックアップを取る形で消すか

rm -rf .vscode-server

などで「.vscode-server」を削除する

そのあと、ローカルのgitのリポジトリなどで

code .

でVisualStuioCodeを起動する。
各、拡張プラグインについて
「アンインストール」
「インストール」
「WSL: Ubuntu-24.04-my にインストール」
の順で押しなおす
青色の！マークが出てるかもしれないが、実際には
なおったりする

以上、なにかの、おまじないか、儀式のような。
手順であるが、これで治ったりしている。
こんなん、覚えられないから、ここに書くことにした。



Linux版のGitKrakenのインストール (Windows版ではないよ)

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
★ \\wsl.localhost\Ubuntu-24.04-my などからはじまるWindowsパスで
★ Ubuntu領域をアクセス時に、大量のファイルや、フォルダにまとめて処理をすると
★ 重たいです。
★ そのため、Ubuntu領域にあるローカルのgitリポジトリに対して
★ Windowsアプリのsourcetreeを使った場合に、大規模gitリポジトリの場合に、
★ 固まってしまい使い物にならないです。
★ 残念ながら、Linux版のsourcetreeのアプリはありません。
★ そのため、Linuxアプリで、Linuxのパスを意識して動作するもので
★ sourcetreeの代わりとして使えるアプリが必要だった。
★ 上記の流れより、Linux版のGitkrakenのインストール方法や
★ Linux版のGitkrakenを使っていく際の考え方を書いてます。
★ ( Windows版のGitkrakenの話ではありませんし、それはネットに沢山、情報あります )
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

WSL2側にgitリポジトリおいてる時、sourcetreeだと大規模gitリポジトリだと
重たく、固まってしまい、使い物にならない。

その代わりとなるものとして、
Linux版のGitKrakenをUbuntu環境にインストールしておく
Ubuntuに日本語フォントも入れて文字化けしないようにしておく

インストール作業に入る前に、ダウンロードしてくるファイルについて
使ってるマシンに応じて、選択する必要がある。

通常のPCやラップトップ（64-bit）: gitkraken-amd64.deb
wget https://release.gitkraken.com/linux/gitkraken-amd64.deb

ARMベースのデバイス: gitkraken-arm64.deb
wget https://release.gitkraken.com/linux/gitkraken-arm64.deb

古いPCや特定の32-bit環境: gitkraken-i386.deb
wget https://release.gitkraken.com/linux/gitkraken-i386.deb

のように自分のマシンを考慮し、調整が必要。

wgetでダウンロードしたファイルをカレントディレクトリに保存する操作が
あるので、/tmpなどに移動してから作業を行うのがよいだろう。

そのうえで、

sudo apt update && sudo apt upgrade -y
sudo apt install -y libasound2 libnotify-bin libnss3 gvfs xdg-utils libsecret-1-0

wget https://release.gitkraken.com/linux/gitkraken-amd64.deb

sudo dpkg -i gitkraken-amd64.deb
sudo apt --fix-broken install -y

sudo apt install -y fonts-noto-cjk
sudo apt install -y ibus ibus-mozc

ibus-setup
↑ これはいらんかも。

gitkraken

と打てば使えるはず


gitkrakenはWSLgという描画方式でlinuxアプリがGUIで動く

この描画は多少重いが、これは固定費用と考えることができる

毎月の家賃は決まった固定費用だが、光熱費などは変動費用であるイメージ

sourcetreeは、\\wsl.localhost\Ubuntu-24.04-my などからはじまる

Windows用のパスを見てる。Windows用のパスでUbuntu領域にアクセスすると

１つのファイルや、ディレクトリへの処理なら問題ないが、複数ファイルやディレクトリを

まとめて処理するような時に、大量だと重たくなる

これは変動費用であるが、大規模gitリポジトリだとsourcetreeは固まって使い物にならない

そのため、固定費用としてのWSLgによる描画のコストを払ってでもGitkrakenのlinuxアプリを

Ubuntu(WSL2)にインストールし、linuxのパスを直接、見るため変動費用を抑える考え方

そのことで大規模gitリポジトリでも使えるようにしようという狙い

ただし、ブランチの切り替えをGitkrakenで行うと、大規模gitリポジトリの時に

クラッシュしてしまう報告があるとのこと

Gitkrakenでのステージングエリアへのファイルの追加、削除は問題になる可能性は低いとのこと

ですので、Gitkrakenは状況確認として、閲覧するだけとして、

変更操作は、ステージングエリアへのファイルの追加、削除だけにしておく

他の変更操作はすべて、ubuntuのターミナル上で、gitコマンドで行うような

使い方をするのがベストだろう

gitHubを対象にGitkrakenを使う分には無料で使うことができる

gitLabなどの他のリポジトリの仕組みを使いたい場合は有料となる




sourcetreeに「\wsl.localhost\Ubuntu-24.04-my～」などのパス指定時のエラーの解決方法

soucetreeに、
\\wsl.localhost\Ubuntu-24.04-my などからはじまるWindows用のパスで

ローカルのgitリポジトリのパスを指定すると、エラーが出る

その場合は、sourcetree上の「ターミナル」ボタンでgitbashを開く

もしくは、

ローカルのgitリポジトリのパスでエクスプローラーで一旦、開く

右クリックで「Open Git Bash Here」を押してgitbashを開く

git logとコマンドを打ち込んでみると

fatal: detected dubious ownership in repository at '//wsl.localhost/Ubuntu-24.04-my/XXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
To add an exception for this directory, call:

        git config --global --add safe.directory '%(prefix)///wsl.localhost/Ubuntu-24.04-my/XXXXXXXXXXXXXXXXXXXXXXXXXXXXX'

などのエラーメッセージが出る。

ここに示された

git config --global --add safe.directory '%(prefix)///wsl.localhost/Ubuntu-24.04-my/XXXXXXXXXXXXXXXXXXXXXXXXXXXXX'

のコマンドをそのまま、gitbashで打ち込む
( XXXXXXXXXXXXXXXXXXXXXXXXXXXXX の箇所なども含め、上記はあくまで例なので
実際には、その時、実際にgitBashで表示されたものをコピペする形で実行してくださいね )

gitbash上の--globalとして、safe.directoryの設定値を記憶させるような意味だと思う



その後、sourcetreeを一回、閉じて開きなおすとエラーがでなくなる

おそらく、sourcetreeが内部的に使ってるのがデフォルトではgitbashであろうが

そこに設定を記憶しエラーがでずにsourcetreeでも情報取得ができるようになる

ただし、sourcetreeをUbuntu領域のローカルのgitリポジトリに対して

「\wsl.localhost\Ubuntu-24.04-my～」などのWindows用のパス指定で

使う方法は、大規模gitリポジトリの場合は、処理が重たく固まって使い物にならないため

前述のGitkrakenを使う方式を検討するのがよいだろう






POSIX ACL

gitリポジトリなどソースコードを管理しているホスト側の領域を
dockerでバインドマウントしているとき、
dockerコンテナ内がrootでフォルダや、ファイルを作ってroot所有になったとき、
ホスト側の一般ユーザで、gitでブランチの切り替えや、プルしたときに、
root所有の箇所について、書き込みや、削除ができなくてエラーになってしまうのを回避したい
また、その領域をWindowsアプリで作業するときに、
一般ユーザーで作業時にroot所有になってしまってるところが権限エラーでできないと
作業しにくいため
gitリポジトリなどソースコードを管理しているルート領域に対して
末端まで権限付与の設定しておきたい。それができるのが、POSIX ACLである。
要するに、ls -lなどで見ることができる、
所有者、所有グループ、パーミンションがどうあれ、
問答無用で、権限付与が行えてしまうような仕組みであり、
しかも、ある基点のフォルダに1回設定してしまえば、配下にその後
作成されていく、ファイルや、フォルダにも適用される。
まさに、前述の★権限問題★の解決策として、有効に使える手段である。

POSIX ACL自体のインストール

sudo apt-get update
sudo apt-get install acl

下記の
/example/path/localGitDir
は、
自分の「gitリポジトリなどソースコードを管理しているルート領域」などを指定する

myuserは、自分の一般ユーザーの名前
mygroupは、自分の一般ユーザーのグループの名前
多分、wsl2のディストロをインストール時に初期ユーザを設定し
それを使うならば、UID=1000、GID=1000で
ユーザー名、グループ名同じになってたりして
それをそのまま指定するイメージで使う場合が多いと思われる

以下はmyUser:myGroupが、/example/path/localGitDirの配下
末端まで（その後、後から配下に新しく作られたファイルや、ディレクトリも対象に)
ls -lなどで表示される一般的なパーミッションに関係なく
rwxの操作についてフル制御で可能にするための設定を行うコマンドである

補足:
ローカルの開発環境なので「rwxの操作についてフル制御で可能」で問題ないでしょう
本番デプロイ時は、別のフォルダで「git clone」からやり直したまっさらな
最新の状態からデプロイ作業するなどして、
本番環境はセキュリティについて考えるので、こんなバカなことはしないです。
あくまで、ローカルの開発環境で★権限問題★を回避し
作業しやすい状況にすればいいですよね。という趣旨です。

それが、下記の、その１）、その２）、その３）である
POSIX ACLは指定したディレクトリに対して、カーネルレベルで、こういった
権限付与を行うための20年ぐらい前からある枯れた技術である
これを使うことで、dockerコテンテナでroot操作しroot所有になってる
ファイルやディレクトリが混在している状況でも、ホスト側の
一般ユーザーでgitのブランチ切替や、その他のファイル作成、更新、削除など
問題なく行えるようにするための設定を行うのが、趣旨である。
毎回、毎回、頻繁に sudo chown -R myuser:mygroup . を
ローカルのgitリポジトリのルートでしたくないからである
これをし忘れてgit操作などでエラーがでて不整合を直すなどの手間をかけたくないからである。
ここで紹介してるPOSIX ACLは一度、設定しとけば後は何もしなくてもよいからである。
なお、wsl2のディストロをインストール時に初期ユーザを対象に行うならば
UID=1000、GID=1000でユーザー名、グループ名同じになってたりするので、
その初期設定した一般ユーザでの作業を意識している場合は、
下記のコマンドでの、myUserとmyGroupは同じ文字列になったりするでしょう。
Ubuntu(WSL2)を開発で使うなら、むしろ、その状況が多いのではないか。
ですから、おそらく
下記のコマンドをメモ帳などにコピペして
myuserとmygroupのところについて、ご自身の初期ユーザ―などの
作業ユーザーの文字列に、置き換えて
/example/path/localGitDir
を、ご自身のローカルのgitリポジトリのルートフォルダ( 直下に.gitがあるフォルダ )
などのパスに置き換えたものを、そのまま、
ターミナルで、その１）、その２）、その３）の順番で
実行する形で作業してもらえればよろしいのではないかと思います。

その１)

sudo setfacl -Rm d:u:myuser:rwx /example/path/localGitDir

その２)

sudo setfacl -Rm d:g:mygroup:rwx /example/path/localGitDir

その３)

sudo setfacl -Rm m::rwx /example/path/localGitDir

この、その３）はumaskの影響が、その１）、その２）に対して効かないように
するためのものとして必要である。
ACLの設定していても、システムのumask値のフィルターがかかって、
設定が効かない箇所が部分的に発生してしまう
その３）のコマンドは、ACLマスク値の設定であり
それをrwxとしているということは、システムのumask値がACLについては、
一切、働かないようにするという意味である
これをしないとうまくいかないよ。
なお、このコマンドは引数指定した該当ディレクトリに対するACL設定への
ACLマスク値の設定をするコマンドであり
システムのumask値は変更しない。

getfacl /example/path/localGitDir

が、上記の、その１），その２），その３）
を確認するコマンドである。


getfacl /example/path/localGitDir

の実行結果が、下記のようになってたら、いけてる

# file: example/path/localGitDir
# owner: myuser
# group: mygroup
user::rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:myuser:rwx
default:group::r-x
default:group:mygroup:rwx
default:mask::rwx
default:other::r-x

上記のうち、myuserとmygroupの記述と

maskの設定の部分の下記の部分が肝である。

# owner: myuser
# group: mygroup
mask::rwx
default:user:myuser:rwx
default:group:mygroup:rwx
default:mask::rwx

また、設定を削除するのは、

sudo setfacl -b /example/path/localGitDir

である。

/example/path/localGitDirに対して設定すれば、

その配下の末端まで設定が適用される。その後、配下に新たに作成された

ディレクトリや、ファイルにも適用される

しかし、下記の注意事項を考慮する必要がある。

＜注意事項＞
設定したディレクトリ配下でchmodコマンドでパーミッションの変更操作をすると
その部分以降の末端まで、局所的にACLが効かなくなるとのこと
大元のディレクトリでACLの設定を消して、また、設定しなおせば、
その無効になった配下の局所的なエリアも含めて元に戻るとのこと
ACLを設定した配下のエリアでは、chmodの併用は避けるようにして、ACLでの制御に統一するか
どうしてもchmodが必要になった場合は、
大元のディレクトリでACLの設定を消して、また、設定しなおす
オペレーションをしてれば問題ない
もっとも、ACLでgitリポジトリ内でmyuserがフル制御できる状況ならば
chmodの必要性はないはずで、めったに考慮の必要はないはず






末端までの再帰的なgrep

Windows環境であれば、よくsakuraエディタのgrep機能で
基点となるフォルダ以降で、キーワード検索してましたが、

Ubuntu領域でそれをやると
\wsl.localhost\Ubuntu-24.04-my\ からはじまるようなWindows用のパスであり、
WindowsとLinuxの変換の関係で検索に時間がかかる

なので、Ubuntu上のターミナルでコマンドを打てばよい。

例として
キーワード：json_decode
対象ファイル : *.blade.php
末端のフォルダまで再帰的に探したいケースでは、
Ubuntu上のターミナルで、検索の基点となるディレクトリをカレントディレクトリとして

grep -r "json_decode" --include="*.blade.php" .

★Visual Studio Codeの検索機能でも代用できたかな★

補足:
厳密には代用できません。/vendorの内部などは、Visual Studio Codeの検索機能では
検索対象にならない。( 理由は不明 )
/vendorなどフレームワーク内部などが検索対象外だったりして、
その中身も含めて検索したいときもあります。
そういう検索対象外にする設定がVisual Studio Code側に便利だと思って
検索対象外にしているんでしょうが、その検索対象外となった箇所を検索したいときもある
そんなときは、ターミナル上で上記のコマンドで検索すればよいだろう。
そんな時には、一応、役に立つ。

説明
-r（--recursive）: カレントディレクトリから再帰的に検索します。
"json_decode": 検索する文字列です。
--include="*.blade.php": 指定されたパターン（この場合は *.blade.php）に一致するファイルだけを検索対象とします。
.で、カレントディレクトリを基点に検索します。

該当するファイル名だけを表示したい場合は
-rでなく、-rlとすればよい

grep -rl "json_decode" --include="*.blade.php" .

なお、末端まで再帰的ではなく、カレントディレクトリの直下だけ探したい場合は、
-rのオプションは不要で

grep "json_decode" --include="*.blade.php" ./*

でよい。



git mergeでエディタを起動しないようにする設定の話

git mergeするときに、マージする内容によっては、
gitは、マージに関するコミットメッセージを自動生成するのであるが、

そのマージに関する自動生成されたコミットメッセージの取り扱いで、

大枠、下記の a)、b)のいずれかの動きを行う設定がある。

  • a)
    マージ処理の途中で、エディタが自動で起動し、
    ユーザに下記の２択をしてもらう
    1、「編集し保存してエディタを終了」
    2、「変更せず、エディタをそのまま終了」
    このことにより、
    必要であれば、メッセージの変更が行える状況で、
    いずれにせよ。
    ユーザがエディタを閉じた後、
    マージ処理を続行し処理を完結させる設定。

  • b)
    a)のためのエディタ起動はせずに、自動生成された
    メッセージをそのまま適用する形で、
    マージ処理を続行し処理を完結させる設定。

の２種類の設定がある。

どうやら、この設定について、
Macと、Ubuntu(WSL2) では、
デフォルトの設定値が異なるようである。

Macは、デフォルトで、上記の b)になっている設定のようだ。
Ubuntu(WSL2)は、上記の a)になっており、しかも、
その時に起動するエディタの初期設定がnanoエディタとなっているようだ。

Ubuntu(WSL2)で、git mergeしたときに、下記のような出来事があった。

現在のブランチが、
feature/hanako/iikanji_no_task
のときに、

git merge develop_chot_iikanji
で、develop_chot_iikanji の内容をマージするときに、
マージする内容によっては、自動生成されたメッセージについて
nanoエディタが起動する。

私は、nanoエディタを使ったことがなく、

git mergeしたら使い方のわからないnanoエディタが、ターミナルの画面いっぱいに

表示されて、いきなり、なんですの？？

と、なりました。

nanoエディタから出られなくなって、あきらめて、ターミナルを「×」ボタンで閉じてしまいました。

すると、git mergeのプロセスが途中で中途半端な状態になってしまったようです。

再度、ターミナルを開きなおして、確認したところ、

期待通りのファイルがマージされていました。

だから、マージはうまくいったと勘違いしました。( ★これが間違いでした★ )

他のチームメンバーのプルリクが承認された分をマージで取り込みたかったので

gitHub上の承認済のプルリクの内容に、一致するソースコードのファイルが

ローカル上にありましたので、マージはうまくいったと勘違いしました。( ★これが間違いでした★ )

ファイルのマージはうまくいってたようですが

マージの途中プロセスで表示されたnanoエディタを

ターミナルごと「×」ボタンで閉じてしまったため

マージのプロセスが途中で強制終了された形となり、後続処理でするであろう

gitの内部的な管理情報の更新がうまくいっておらず、

ファイルは確かにマージされたが、gitの内部的な管理情報としては、マージされていない

ような状況となってしまいましたが、それに気づかず

そのまま、自分の分をコミットおよび、プッシュし、プルリクをだして、

最終的にそれが承認されて、develop_chot_iikanjiにマージされました。

その後、develop_chot_iikanjiでプルした時に、

私の１つ前の

他のチームメンバーのプルリクでのコミット分が丸ごと削除された

形になってしまいました。

最終的に、その修正のプルリクで対応したが、ご迷惑をおかけする結果となった。

この失敗をうけて、

下記のように、Ubuntu(WSL2)では対応しておくべきだと考えました

チーム開発してる際、Macユーザが b)のデフォルト設定で、
git merge しているんだから、git mergeの際は、自動生成されたメッセージをうけいれて開発作業をしている
だから、チーム内で「git mergeの際の自動生成されたメッセージ」についての
特別なルールや、決め事がなければ、
Ubuntu(WSL2)側も、b)の設定でよろしいであろう。

しかし、環境作った時に、b)の設定にしておくこと自体を忘れてしまってて
同様の失敗を繰り返すことが無いように、

１）

git merge --no-edit develop_chot_iikanji

常に「--no-edit」をつけておくことにしよう
さすれば、b)のモードで、途中でエディタを開くことがなくマージ処理が完結するとのことだ。

私は、記憶力があまりなく、どうせ、このようなコマンドは、
どこぞのメモ書きからのコピペ編集だから、そこのメモ書きに
「--no-edit」を書いとけば、コピペ編集の手間としては
たいして、変わらないから、それでよし
そのメモ書き自体を紛失しても、当サイトのここの記述に
アクセスすれば、問題なし

次に、

２）

git config --global core.mergeoptions --no-edit

を打ち込んで設定しておき
git config --global core.mergeoptions
を打ち込んだときに、
--no-edit
と表示される設定にしておけば
git mergeは、b)モードで動いてくれるとのこと

３）
ログインプロセスで読み込むようなシェルに

export GIT_MERGE_AUTOEDIT=no

を追記しておき
echo $GIT_MERGE_AUTOEDIT
としたときに、
no
と表示される状態にしておけば
git mergeは、b)モードで動いてくれるとのこと

上記、１）、２）、３）のどれか１つでもあれば、
git mergeは、b) のモードで動くが
念のため、全部、やっておいてもよろしかろう。
Macは、おそらく、２）、３）のいずれかが、
デフォルトで入ってるから、
デフォルトでgit mergeが b)モードで動くのではないか

そして、万が一にでも、gitコマンドで( git mergeに限らず )
エディタが起動することがあっても、
使い方がわからないnanoエディタが起動するのではなく
使い方を知ってるエディタが起動してくれるように

git config --global core.editor vim

をしておき
git config --global core.editor
と打ち込んだときに、
vim
と表示される状況としておき、vimエディタが起動することを期待したい
ただし、これは、本当に効いてくれるかは不明
もし、なにかの事情でgitコマンドから
エディタが自動起動されることが、もし、あって
そのとき、vimエディタが起動した
もしくは、残念ながらnanoエディタが起動した
その事象を見て、この記事の、
ここの記述内容をまた、更新することに、いたしましょう





git push時にPATトークンが求められる問題

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
１つ下の項目の
目次の項目の「PATトークンの入力なしで、git push可能にするため、Windows側の認証機能を間借りする方法」
で、Windows側の認証機能を間借りした形で、
git pushするようにしたら、PATトークンの入力を省略できることがわかりました。
なので、その方法でしたい人は、
目次の項目の「PATトークンの入力なしで、git push可能にするため、Windows側の認証機能を間借りする方法」
を参照してください。
そこに書いた方法で設定すれば、
gitBashや、Macのgitコマンドと同様に、PATトークンの入力なしで
git pushが可能な環境になるでしょう。

それでも、プッシュすべき内容物によってはPATトークンが必要になってしまう
こともあるのか？
その場合は、ここの項目も参考に読んでください
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

Ubuntu(WSL2)上でのgitコマンドでgit pushするときに、

パスワードが求められたときに、そこに、PATトークンをコピペ入力しないと

権限エラーでリモートへのpushができないことがある

remote: Support for password authentication was removed on August 13, 2021.
remote: Please see https://docs.github.com/get-started/getting-started-with-git/about-（中略）
fatal: Authentication failed for 'https://github.com/XXXXXXXXXXXXXXX

上記のようなエラーメッセージが表示されて

リモートへのpushができない問題がある。

2021/08/13よりgithubのポリシーが変わったようであるが

なぜか、gitbashや、Macでのgit push時は、この問題が発生しないとのこと

その理由は不明である

ただ、Ubuntu(WSL2)上でのgitコマンドでgit pushするときには、

この問題が発生する。

その回避策としては自分のアカウントでgitHubのサイトにログインして

PATトークンを取得し、それをgit push時にパスワードを求められた時に

アカウントのパスワードの代わりに、PATトークンの文字列をコピペ入力すれば

git pushが成功することがわかっている

https://nlab-notebook.com/entry/2023/04/23/200000
にてPATトークンの作成方法が書かれている

https://qiita.com/ryomoucmei/items/ec8c225603ef983fc318
のサイトの情報も参考になる。
とりあえずは、repoだけのチェックでよいだろう

ただし、pushすべきものによってはrepo以外のものも必要な場合がある

fly.ioへのデプロイのために作成されたファイルをpush時に、

repoだけでは対応できないファイルがあり、repoだけチェックして作った

PATトークンでは、pushできない問題があった

そのため、workflowもチェックを入れたPATトークンを新たに取得し

そのPATトークンをアカウントのパスワードの代わりにコピペ入力したところ

git pushに成功したという経緯もあるので、ご参考にしてください



こんなことをしなくても、そもそも、gitbashや、Macのgitコマンドのように普通に

やってても、git pushができる方法を知ってる人がいたら教えてほしいぐらいである

がわかりました！！
すぐ下の、目次の項目の「PATトークンの入力なしで、git push可能にするため、Windows側の認証機能を間借りする方法」
に書きました。

PATトークンの入力なしで、git push可能にするため、Windows側の認証機能を間借りする方法

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
gitbashや、Macのgitと同じようにPATトークンの入力なしで普通に
git pushできる状態にするための設定を書いてます。
gitbashや、Macのgitも、OS側にある認証機能を使ってるのではないか
それと同様に、Windows側の認証機能を間借りする設定にすれば解決できました。
Ubuntu(WSL2)だけでは解決しようと設定すると困難（できるかもしれんが難しいものなど)
なものは、今回みたいにWindows側を間借りするような手立てで乗り切ればよいだろう。
認証処理だけの間借りなので、ほとんどパフォーマンスは低下しないはずである
このようにほとんどパフォーマンス低下しない事柄でのWindows側の機能の間借り戦略は
Ubuntu(WSL2)利用時のやり方として有効なのだろう
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

新しいディストロの環境でこの方法で試したら、
1度目からPATトークンの入力を求められなかったのを動作確認しました。

ですので、おそらく、ここに書いた方法で
Windows側の認証機能を間借りすれば、
gitBashや、Macのgitコマンドと同様に、PATトークンの入力なしで
git pushが可能な環境になるでしょう。

Windows環境にインストールされたGit for Windowsの認証の機能を利用することで
解決できる。
私の環境では既に、Git for Windowsがインストールされており
C:\Program Files\Git\mingw64\libexec\git-core
に
git-credential-wincred.exe
が存在した。
( インストールしていない人は、Git for Windowsのインストールを先にしてください )

そのうえで、Ubuntu側でターミナルで、
下記のコマンドを実行します。

git config --global credential.helper "/mnt/c/Program\ Files/Git/mingw64/libexec/git-core/git-credential-wincred.exe"

「Program\ 」の\記号が気になるがこれは、隣のスペースをエスケープするために
Bashや、zshの仕様として入れとかなきゃいけないらしいです。

Ubuntuのターミナル上で、
スペースのエスケープのために上記で指定した\を除いたイメージのパスでls -lしたときに
ファイルがちゃんと見えていて、git操作を行う作業ユーザで実行権限があるのかどうかを確認してください
このあたりができてないと多分、うまくいかないとおもいますよ

ls -l "/mnt/c/Program Files/Git/mingw64/libexec/git-core/git-credential-wincred.exe"

ちなみに、上記の解除は、

git config --global --unset credential.helper

であり、

git config --global credential.helper

で何も表示されなければ解除できてるとのこと

現状では、
Ubuntu(WSL2)自体のgitの認証系は発展途上な様子で
Ubuntu単体で機能拡張しようとすると、aptパッケージマネージャでのインストール方法が
標準的に搭載されていない様子。
Windowsのものを間借りする方法が現実的な様子。

上記の方法は、Windows側のgit-credential-wincred.exeを通じて
WindowsのGitHubに対する資格情報にアクセスし、
認証を解決するので、PATトークンの入力を免除された形で
git pushを成功させる方法である。

★★★★★★★★★★★★
ファイル、ディレクトリへのアクセスはUbuntu側で行い
単なる認証処理の間借りであるため、
この間借りそのものでは、WindowsとLinux間の変換にまつわる
パフォーマンス低下はほぼ発生しないとのこと
★★★★★★★★★★★★



gitの「リモート追跡ブランチをローカルブランチ化」方法

ローカルには、まだ、存在しないが、他のチームメンバーが更新中のリモートにあるブランチを
ローカルにもってきたい。

つまり、「リモート追跡ブランチをローカルブランチ化」の件ですが、

https://note.com/llminatoll/n/na33651a6dc3e
にて、

リモート追跡ブランチをローカルブランチ化して、自由にコミット等の操作ができるようにしたいですよね。

と書いてあり
soucetreeでのやり方が書かれています。

Ubuntu(WSL2)での開発時は、おそらく、git変更操作は、ほぼ、gitコマンドで行うことになると思いますので
上記と同内容のことをgitコマンドで行う方法を、ここで紹介します。

リモート追跡ブランチをローカルブランチ化して、自由にコミット等の操作ができるようにしたいですよね。

というのが、まさにそれで、それができるようにしたい。
そのやり方です。

git remote -v

を打ち込んだときに、

origin  https://github.com/hogehoge/foo_bar.git (fetch)
origin  https://github.com/hogehoge/foo_bar.git (push)

みたいな表示がでてくるです。

https://github.com/hogehoge/foo_bar.git

の部分は、おそらく、同じだったりしてて
(fetch)、(push)で２行でてくるのですが
一番左が、originになってたら、( おそらく、originになってることが多いけど )
後述のコマンドのところは、「origin/」でいいんです。
そうじゃなくて他の値だったら、後述のコマンドの「origin/」の部分は、
「他の値/」に変えたやり方にするというのが、まず、注意点としてあります。

そのうえで、

まず、とりあえず、

git fetch --all

を打ち込んでおくのが、よろしいみたいです。( おまじない　です )

その後に、

git checkout -t origin/develop

「-t」で 「origin/」をつけるよ。「git remote -v」の結果がoriginでなく
他の値だったら「他の値/」をつけるよ。

とか

git checkout -t origin/feature/hanako/iikanji_no_task

「-t」で 「origin/」をつけるよ。「git remote -v」の結果がoriginでなく
他の値だったら「他の値/」をつけるよ。

などとすれば、「リモート追跡ブランチをローカルブランチ化」
で、

リモート追跡ブランチをローカルブランチ化して、自由にコミット等の操作ができるようにしたいですよね。

が、行える状況となる

この「-t」のtは、tracking:追跡 の tだそうです。
「origin/」の部分は、前述の「git remote -v」が、originでなく他の値だったら
「他の値/」にするのは、注意のこと。

補足:
「git checkout -b」で「-b」は現在のブランチから作るので
コマンド打つときの、現在のブランチが重要ですが、
今回の「git checkout -t」で「-t」の場合は、
リモートを元に新しいブランチを作成してチェックアウトするコマンドで、
コマンドを打つときに、現在どのブランチにいるかは結果に影響しません

では、ここで紹介したやり方は、

どんな時に、必要か

  • 新しい環境で、git cloneしなおした状況
  • 途中、参加メンバーの環境構築時
  • 本番デプロイ作業に先立って、最新状態をまっさらな形でローカルに落としたい時

など、ではないか。

「新しい環境で、git cloneしなおした状況」は、
なにかの事情で、ローカルのgitリポジトリの位置を変えたとか
端末自体を変更したとか、まっさらな状態でgit cloneしたとき
ローカルにあるブランチをみたとき、main( もしくは、master )ぐらいしかなく、developすらローカルにはない

「途中、参加メンバーの環境構築時」は
途中、参加の人だから、まっさらな状態でgit cloneしたとき
ローカルにあるブランチをみたとき、main( もしくは、master )ぐらいしかなく、developすらローカルにはない

「本番デプロイ作業に先立って、最新状態をまっさらな形でローカルに落としたい時」の件ですが
各自のローカルでの開発作業は、いろんな諸事情で、
本番デプロイ用としてふさわしくないかもしれない
ide-helperなど、ツールのインストールでartisanバイナリや、composer.json, composer.lockなどが個人用になってるかもしれない

ステージングにも追加していない、テストドライバーや、スタブがローカルに残存していたり
いろんなタスクを並行して実行しているうちに、ローカルにゴミがあったりするかもしれない
なので、
本番デプロイ作業に先立って、最新状態をまっさらな形で、別のフォルダで、git cloneしてから
それを元にして、本番デプロイ作業をすべきではないか
当然、そのときは、
ローカルにあるブランチをみたとき、main( もしくは、master )ぐらいしかなく、developすらローカルにはない

★あ！！、本番デプロイだから、main( もしくは、master )だけ、あればよいのか！！★★

うーん、では、本番デプロイ時でなく

なにかの、疑似本番環境(結合テスト、システムテスト環境)などへの
デプロイ時のためなら、
developなどは、必要でしょう。



ローカル編集中の内容を元に戻す方法( git現在のブランチの最新リビジョン（HEAD）に戻す )

ローカルで編集中のファイルを、現在のブランチの最新リビジョン（HEAD）に戻す方法を書きます

ローカルのgitリポジトリのルートで、コマンド打ち込みますが
そこから見た時の、相対パスが
dir1/subDir1/fileA
のファイルに対して、行う例で、示すと

git checkout HEAD -- dir1/subDir1/fileA

です。

Javaをやってないとわからない話だがeclipse上で、
対象の編集中のファイルを右クリックし、
「チーム」メニューから「置換」を選び、その後「HEADリビジョン」を選択することで、
そのファイルを現在のブランチの最新リビジョン（HEAD）に戻します。
これと同じ操作をgitコマンドでする方法が、上記のコマンドです。

補足:
ステージングに追加してる、してないにかかわらず、使えるとのこと
ステージングに追加してたら、ステージングから外したうえでファイルの内容を
最新リビジョン（HEAD）に戻すとのこと
コミットまでしたファイルについては、最新リビジョン（HEAD）が変わるので
その状況では当コマンドは意味がないので、git resetなどを考慮する必要あり

Ubuntu(WSL2)とは、直接的に関係のない話かもしれないが
Ubuntu(WSL2)環境で開発するのであれば、gitはコマンド操作で、
ほぼ、すべてやり切る必要があるため当項目を追記しました。

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
　プルと「git checkout HEAD -- なんとか」の関係性
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

まず、前提として

gitでのプルしようとしたときに、
「マージ」や「コンフリクト」という概念は
ローカルでコミット状態にあるものを対象にした概念である

プルしようとしたファイルと競合するファイルが
ステージングや、未ステージングにある場合は、
プルは単にエラーとなり、結果として、何も実行されない

この基本を抑えつつ

プルと「git checkout HEAD -- なんとか」の関係性
について考えていく

ケーススタディとして、

他の人が担当分の実装を暫定値での仮実装でも、
ローカルの未ステージング領域で変更したり、
追加しておかないと自分の実装が動作確認できないような時がある。

テストドライバーのような実装をローカルで準備し
自分の実装は動作確認する

しかし、そのテストドライバーのような実装は
自分はコミットや、プッシュをしないため

当然、未ステージングに置きっぱなしである

developのブランチに、いるときでさえ

未ステージングに置きっぱなし

そんなときに、

たとえば、

git pull origin develop_chot_iikanji

などでプルしたときに、
未ステージング領域と同じパスのファイルが、
リモートから取り込もうと試みてエラーになる

そんな時に、役立つ。
「git checkout HEAD -- なんとか」
なのである。

git pull origin develop_chot_iikanji

時に、

error: The following untracked working tree files would be overwritten by merge:
hogehoge/bar.blade.php

などのエラーメッセージでプルができない

そんなとき自分がテストのためにローカルで変更して、未ステージングにあったものについて、
本チャンの実装分が、来たということだったりする

そういうときに、

git checkout HEAD -- hogehoge/bar.blade.php

して、hogehoge/bar.blade.phpを元通りにしてから

再度、プルするとうまくいくのである

git checkout HEAD -- hogehoge/bar.blade.php
というのは、
現在のブランチのローカルの最新のコミット（HEAD）
に、hogehoge/bar.blade.phpを戻すという意味である
あくまで、ローカルの最新のコミット（HEAD）に戻すって
ことでリモートは関係ありません
ローカルの最新のコミット（HEAD）に戻ることで
未ステージングから消えます
それで、リモートからプルできる準備ができたということです。

その状況で、プルでリモートから取り込むので、今度はエラーにならないのである

もし、

git checkout HEAD -- hogehoge/bar.blade.php

の時に、

error: pathspec 'hogehoge/bar.blade.php' did not match any file(s) known to git

が出たりするのは、単に、gitは、そんなの知らない

と言ってる

それは、自分の実装の動作確認のため、周辺ものを、新たに追加( 変更ではなく )
してたものだったということだったりする

当然、ローカルのコミットにないわけで
gitは、そんなの知らない
と言っている

その場合は、純粋に、

rm hogehoge/bar.blade.php

で削除してから、プルをやり直すと、うまくいったりする

くれぐれも、いきなり、rmで削除するのはやめよう
gitが知ってるものをrmで削除すると
削除したという差分が、未ステージング領域に上がるため
これがまた、エラーの原因になる

git checkout HEAD -- なんとか

をやってみて、gitに知らないと言われたから
rmするという流れが重要である

＜＜俗っぽい言葉で言いなおすと＞＞
プルしてみて、怒られたものがあれば
gitが知ってたら元に戻してもらって、再度、プルする
知らないよと言われたら
削除してから、プルする

＜＜上記の作業をはじめる前の注意事項＞＞
ローカルに未ステージング領域で、テストドライバー関連の実装が混在してる状況などで
プルを成功させるまでの、やり方としては、たしかに
上記のやり方は効率がよい。
しかし、
その過程で、該当箇所のテストドライバー実装が無くなってしまうので
事前に、退避してから作業をしていたほうがよろしいかと思うです。
その理由は、周辺のそれらのテストドライバー実装の該当箇所の
本チャンの実装をしている担当者のプルリクが承認され、
それを取り込んだ後、自分の実装と結合しての動作確認を
する必要がある
そのとき、うまく結合動作しなかったときの調査として
自分が実装してた時に使ってたテストドライバー実装との
比較で、モジュール間のインターフェースが整合とれているかの
調査の役に立つからだ。
また、テストドライバー実装を保管して、それを
チームメンバーに共有しておけば、
はじめから、意図通りのインターフェースで実装してくれる
可能性が高まり、結合した時に、うまく連携して動作する
可能性が高まるはずで
そういったことに使えるテストドライバー実装が
プルを成功させるのに、効率がよいやり方のプロセスの中で
消されていく前に、退避しておくのがよいだろう
なるべく、自分の分が動作確認がうまくいって、
プルリクが承認される
この時点のテストドライバー実装を保存するのがよい
その途中に、他の人の分でプルするときに
怒られるなどして、なかなか、理想のタイミングでの
保管がかなわないかもしれないが、
めんどい、かもしれないが、何度も、世代管理で保管して
とんでしまわないように、また、できるだけ
直近のタイミングのテストドライバー実装が保管しておくように
注意を払えば、その時点の、保管を気にするのは、
たしかに、めんどいが
後で、楽ができるではないだろうか
★★★★★★★★★★★★★★★★★★★★★★★★★★★★

＜これが調べた理由＞
★★★★★★★★★★★★★★★
（理由１）
★★★★★★★★★★★★★★★
featureAについてのプルリクエストを出したが、まだ、レビュー中である
developより、featureBを作り、次のタスクを開始したい
そのときに、featureAの内容をローカル上で手作業でfeatureBに反映し
そのコードも利用して、featureBの作業をしたい
ところが、後々に、featureAのレビューがOKとなり、
developにマージされた後に、developをプルする。

developからfeatureBへのマージすることになるが
その前に、
先ほど、「featureAの内容をローカル上で手作業でfeatureBに反映し」

の部分を元に戻してから
developからfeatureBへのマージしないと不整合になるのではないか
と思われる。
このときに、元に戻す、操作をするために

developより、featureBを作った時点に、該当ファイルを元にもどしたい

それをやるためのコマンドとして、使えるものを調べたかった
★★★★★★★★★★★★★★★

★★★★★★★★★★★★★★★
（理由２）
★★★★★★★★★★★★★★★
単に、実装をしてて、大きく失敗したので、純粋に元通りにしたいときに
使えるのではないかと思ったから。
★★★★★★★★★★★★★★★

★★★★★★★★★★★★★★★
（理由３）
★★★★★★★★★★★★★★★
上記で、記載した
　プルと「git checkout HEAD -- なんとか」の関係性
のとおり
プルするときに、邪魔になる未ステージングのファイルを
効率よくどかして、プルを成功させる
手段として、非常に有効だから
★★★★★★★★★★★★★★★

git pullのエラーメッセージで判断できる

1つ上の目次項目の「ローカル編集中の内容を元に戻す方法( git現在のブランチの最新リビジョン（HEAD）に戻す )」にて、

くれぐれも、いきなり、rmで削除するのはやめよう
gitが知ってるものをrmで削除すると
削除したという差分が、未ステージング領域に上がるため
これがまた、エラーの原因になる

git checkout HEAD -- なんとか

をやってみて、gitに知らないと言われたから
rmするという流れが重要である

ということを書きましたが、
git pullのエラーメッセージを見ただけで

  • 「git checkout HEAD -- なんとか」をすべきもの
  • rmで削除すべきもの
    のいずれかが、わかります。

★★★★★★★★★★★★★★★★★★★★★★★★★★★
★ エラー内容を見て、対処方法を判別してしまう考え方 ★
★★★★★★★★★★★★★★★★★★★★★★★★★★★

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
その１）「git checkout HEAD -- なんとか」でよし　のエラー
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

error: Your local changes to the following files would be overwritten by merge:
    hogehobe/aaa.blade.php
    hogehobe/bbb.blade.php
    hogehobe/ccc.blade.php
Please commit your changes or stash them before you merge.

英語)
error: Your local changes to the following files would be overwritten by merge:
日本語)
エラー: 次のファイルに対するローカルの変更はマージによって上書きされます:

英語)
Please commit your changes or stash them before you merge.
日本語)
マージする前に変更をコミットするか、隠してください。

この場合に対処法

git checkout HEAD -- hogehobe/aaa.blade.php
git checkout HEAD -- hogehobe/bbb.blade.php
git checkout HEAD -- hogehobe/ccc.blade.php

★このコマンドを打ち込む前のタイミングにて、これがテストドライバーに該当時するなら
★保管しておいて、他のチームメンバーへのインターフェースの連絡や、
★後々の結合動作時の不具合調査のためのネタとすればよい
★という考え方ができる。

カレントディレクトリが、ローカルのgitリポジトリのルートフォルダ
でgit pullのコマンドを打ち込んでるはずだと思います。
なので、エラーに書かれている相対パスそのまま、コピペしてコマンド実行すればよい。

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
その２）「rm なんとか」でよし　のエラー
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

error: The following untracked working tree files would be overwritten by merge:
    hogehobe/ddd.blade.php
    hogehobe/eee.blade.php
    hogehobe/fff.blade.php
Please move or remove them before you merge.

    hogehobe/ddd.blade.php
    hogehobe/eee.blade.php
    hogehobe/fff.blade.php

英語)
error: The following untracked working tree files would be overwritten by merge:
日本語)
エラー: 次の追跡されていない作業ツリー ファイルはマージによって上書きされます:

英語)
Please move or remove them before you merge.
日本語)
結合する前に、それらを移動または削除してください。

この場合の対処法

rm hogehobe/ddd.blade.php
rm hogehobe/eee.blade.php
rm hogehobe/fff.blade.php

★このコマンドを打ち込む前のタイミングにて、これがテストドライバーに該当時するなら
★保管しておいて、他のチームメンバーへのインターフェースの連絡や、
★後々の結合動作時の不具合調査のためのネタとすればよい
★という考え方ができる。

カレントディレクトリが、ローカルのgitリポジトリのルートフォルダ
でgit pullのコマンドを打ち込んでるはずだと思います。
なので、エラーに書かれている相対パスそのまま、コピペしてコマンド実行すればよい。

★★★★★★★★★★★★★★★★★★★★★★★★★★★

あと補足しとくと、git pullはエラーメッセージの最後に
Aborting　という文字を出力してます。
これは、結局、エラーがあるので何も変更しなかったという意味だと思います。

Ubuntu(WSL2)でもbrewコマンドは使える

linuxには、apt、yum、pacmanなどのパッケージ管理ツールがある。

どのパッケージ管理ツールを使うかは、linuxのディストリビューションによって異なる。

Macでのパッケージ管理はHomebrewでbrewコマンドのようです。



「Homebrew on Linux」をインストールすれば、Ubuntu(WSL2)でもbrewコマンドが使えます

たいていは、aptパッケージマネージャを使えば代用できるとは思うが

もし、Macユーザが環境構築方法をbrewコマンドを使った方法しか準備しておらず

brewが使えないとインストール困難なものが、もし、有った場合は

「Homebrew on Linux」をインストールしてから、brewコマンドでのインストール

すればよろしいだろう。

というわけで、ここでは、「Homebrew on Linux」のインストール方法を記述する

「Homebrew on Linux」は一般ユーザでのインストール作業となるため

rootにはならず、一般ユーザのまま作業をすすめる

brew --version

で何も表示されなかったり、エラーになったら未だインストールされていない
インストールするには、

sudo apt update
sudo apt upgrade
sudo apt-get install build-essential
/usr/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

を実行する。
sudo apt-get install build-essential
を先にやっておく必要があるとのこと。

/usr/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
を実行したときに、
下記のようなログが出力される
****
==> Next steps:
- Run these two commands in your terminal to add Homebrew to your PATH:
    (echo; echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"') >> /home/myUser/.bashrc
    eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"
- Install Homebrew's dependencies if you have sudo access:
    sudo apt-get install build-essential
  For more information, see:
    https://docs.brew.sh/Homebrew-on-Linux
- We recommend that you install GCC:
    brew install gcc
- Run brew help to get started
- Further documentation:
    https://docs.brew.sh
****

上記のログより、拾ってくる形で

(echo; echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"') >> /home/myUser/.bashrc

を実行し、作業している一般ユーザーの環境変数を設定する。

あくまで上記コマンドはログで指示されたものを拾ったものを使う。

その後、

brew install gcc

を実行すると

「brew install gcc」では、

/home/linuxbrew/.linuxbrew/bin

配下に

c++-14

cpp-14

g++-14

gcc-14

などのシンボリックリンクができる

これはbrewの中での何かのインストール作業に用いるためのものであろう

システムの

/usr/bin/gcc

/usr/bin/g++

とは、別個に「Homebrew on Linux」用として存在する形となる。



brew --version でバージョンが出てきたらインストールできてる

$ brew --version
Homebrew 4.3.9




Laravel環境で未実施のマイグレーションの扱い

自分が作成した状況、もしくは、他の人の承認済のプルリクを取り込むなどして
未実施のマイグレーションがあったとき、
現在のテストデータは、維持したいため、
php artisan migrate:fresh
や
php artisan migrate:fresh --seed
までのことはしたくない時など

php artisan migrate:status
と打ち込む。
するとどこまでのマイグレーションを実行したのかYes, Noでリスト表示される。
それで、冒頭で言ってる

自分が作成した状況、もしくは、他の人の承認済のプルリクを取り込むなどして
未実施のマイグレーションがあったとき
に相当するマイグレーションだけ、No
になってるケースなど
現在のテストデータは、維持したいたが、そのテーブルだけは
動作させるために定義したい

そんなとき
php artisan migrate
だけ実行しておく

再度、
php artisan migrate:status
と、先ほど、NoになってたマイグレーションもYesになって
該当のテーブルがDB上、定義されるだろう

Laravel環境でのキャッシュクリア

Laravel関係で原因不明のエラーが出て、困ったときに
キャッシュのクリアをすると
解消されたことが何度もありました。

そのたびに、キャッシュをクリアするコマンドが何かをメモ書きしたものを
探したり、ググったりしてたのが、めんどいので
ここに書いておくことにした。

補足:
どういう条件かは、詳しくは忘れてしまったが
dockerコンテナ側をイメージのbuildからやり直して、起動しなおす
みたいなことをして、
それでも、ソースコードや、DB定義や値は、
ホスト側で、前のが保存されています。

そのような状況の時など、
他にも、再現パターンはあるかもしれないが

とにかく、キャッシュ内容が、現状の実態とズレているがゆえに
おかしくなって、意味不明のエラーがでるような事が
たまに、あったりする

そのときに、下記のコマンド群を片っ端から打ち込んだら
ほぼ、解消された。
それでも解決しなければ、
storage/logs/laravel.log
などを見て、出てるエラーでググって頑張るしかないですね。

php artisan config:clear
php artisan cache:clear
php artisan route:clear
php artisan view:clear
composer dump-autoload

各々の説明は、下記のとおり

php artisan config:clear
キャッシュされた設定ファイルをクリアします。次回アクセス時に、設定が再読み込みされます。

php artisan cache:clear
アプリケーション全体のキャッシュをクリアします。これにより、キャッシュされたデータが削除され、次回のアクセスで新しいキャッシュが生成されます。

php artisan route:clear
キャッシュされたルート情報をクリアします。これにより、新しいルートが次回のアクセスで再生成されます。

php artisan view:clear
キャッシュされたBladeテンプレートのコンパイル済みビューをクリアします。次回のビュー表示時に、ビューが再コンパイルされます。

composer dump-autoload
Composerのオートローダーを再生成します。新しいクラスやファイルが追加されたときに、これを実行してオートローディングに反映させます。





dockerを使って環境構築時は、
基本的には、永続化したい情報は、ホスト側においてることでしょう。
ソースコードや、composerでのインストール内容や、
MySqlのDBの定義や、設定値のバイナリファイルなど
こういったものは、バインドマウントなどの、その他、マウントでホスト側を見に行く
環境設定が普通だと思います。
だから、dockerコンテナ側を削除してbuildからやり直しても
基本的には、必要な情報は復元されていると思います。


なので、基本的には、ここまでの説明で事足りることが多いと思います。


ただし、何かの事情があり、ホスト側の配置場所が変わるなどして
最初から環境構築時など、DB情報が初期だったりして、
現段階のソースコードで動かしたときに、テーブル定義やデータがなくて
動かないみたいな話の場合、
マイグレーションや、シーダーを既に実装している状況であれば
少なくとも、.envの設定がなされてDBアクセスができる状況ならば
★.envの設定がなされてDBアクセスができる状況でないと下記のコマンドは動きません★

php artisan migrate:fresh --seed

にて、マイグレーションとシーダーを動かして
テーブル定義や、データを作り直せばよろしいでしょう



Laravelでの画像のアップロードおよび表示のお作法

アップロード自体は、storage/app/publicの配下に行うのがお作法である
しかし、この領域は公開されていないため、公開領域への
シンボリックリンクを作成する必要がある。

php artisan storage:link

実行例)
# php artisan storage:link
The [public/storage] directory has been linked.

を打てばシンボリックリンクができる。
このコマンド自体が、
storage/app/public
のディレクトリに対するシンボリックリンクを
public/storage
で作ることだけをやる専用のコマンドである。
上記、コマンドを打ち込んだ後の環境においては、
storage/app/public/foo/bar/baz.jpg
のパスにアップロードなどで保存したのであれば、
public/storage/foo/bar/baz.jpg
というパスでシンボリックリンクを通じて、
公開領域のパスとして見える。
それを、*.blade.phpにて、imgタグで表示する実装としては、

<img src="{{ asset('storage/foo/bar/baz.jpg') }}" alt="baz">

のやり方になります。

補足:
http://localhost:8080/storage/foo/bar/baz.jpg
などのURLで「baz.jpg」の画像がブラウザ上で表示できる状況であり、
{{ asset('storage/foo/bar/baz.jpg') }}
が
http://localhost:8080/storage/foo/bar/baz.jpg
のURLを返し、それをimg タグの src属性に指定しているイメージである。

dockerコンテナ内部でのパスで
storage/app/public の絶対パスに対して、
public/storage のシンボリックリンクができるため
ホストマシン側でpublic/storageを見た時に、
中のstorage/app/public側にはいっていけない
ただし、ホストマシン側から、そこにファイルを置きたいケースがある
この時は、下記のようなコマンドを行う

docker cp <local_file_path> <container_name_or_id>:/var/www/html/laravelapp/storage/app/public

例)
例えば、WindowsのPC内の
C:\path\to\your\image.jpg 
を、WSL2環境のNTFS領域のマウントパス/mnt/cを通じたパスで
コピー元を指定するやり方で、
/mnt/c/path/to/your/image.jpg
として、行うの場合の例として

docker cp /mnt/c/path/to/your/image.jpg <container_name_or_id>:/var/www/html/laravelapp/storage/app/public/image.jpg

Ubuntuのext4領域がコピー元の場合は普通にLinuxのパスをコピー元に指定すればよい。

補足:
こんなことしなくてもバインドマウントしてる状況なら
普通にホスト側で
storage/app/public のほうを開けて、そこにファイルを置けた
と後で気が付いた


storageフォルダの所有者をapacheの実行ユーザにしておく

dockerコンテナ内のapacheの実行ユーザが
ユーザ名 : www-data
グループ名 : www-data
であることを確認したうえで、

# ps -ef | grep "apache"
root           1       0  0 01:05 ?        00:00:01 apache2 -DFOREGROUND
www-data      31       1  0 01:22 ?        00:00:02 apache2 -DFOREGROUND
www-data      37       1  0 01:52 ?        00:00:00 apache2 -DFOREGROUND
www-data      41       1  0 03:18 ?        00:00:01 apache2 -DFOREGROUND
www-data      42       1  0 03:37 ?        00:00:00 apache2 -DFOREGROUND
www-data      43       1  0 03:37 ?        00:00:01 apache2 -DFOREGROUND
www-data      44       1  0 03:43 ?        00:00:00 apache2 -DFOREGROUND
www-data      46       1  0 05:06 ?        00:00:01 apache2 -DFOREGROUND
www-data      47       1  0 05:06 ?        00:00:00 apache2 -DFOREGROUND
www-data      63       1  0 07:13 ?        00:00:00 apache2 -DFOREGROUND
www-data      78       1  0 07:24 ?        00:00:00 apache2 -DFOREGROUND
root          85      48  0 07:28 pts/0    00:00:00 grep apache
#
# id www-data
uid=33(www-data) gid=33(www-data) groups=33(www-data)
#

storageフォルダに対して下記をしておく

# chown -R www-data:www-data /var/www/html/laravelapp/storage
# chmod -R 775 /var/www/html/laravelapp/storage

★これをやっておかないと、プログラムでアップロードしたファイルを保存できなかった★

Laravelでアプリ開発者が作る*.js,*.cssの置き場所

アプリのルートからの相対パスで

public/css/foo.css
public/js/bar.js

のように配置する

*.blade.phpからは、

<link href="{{ asset('css/foo.css') }}" rel="stylesheet">

<script src="{{ asset('js/bar.js') }}"></script>

のように使うのであるが、ブラウザのキャッシュなどで反映されないことがあり
それを防ぎたい場合は
気のせいでした。他が間違ってました。そんなことはないと思う
めったにおきない

これは、別にやらんでもよさげ、
他が間違ってて、ハマった時にためしたが、
結局、要らんかったので、あんまり気にしなくてもよい

<link href="{{ asset('css/foo.css') }}?v={{ time() }}" rel="stylesheet">

<script src="{{ asset('js/bar.js') }}?v={{ time() }}"></script>

のように書けばよい。
このような方法を「キャッシュバスティング」というらしい。
そんなんせんでも、いけそう

Dockerネットワーク

今のあるものを一覧を表示する

docker network ls

「xdebug_network」というdockerネットワークの詳細を調べる

docker network inspect xdebug_network

「xdebug_network」というdockerネットワークを作成する

docker network create --driver bridge xdebug_network

「xdebug_network」というdockerネットワークを削除する

docker network rm xdebug_network

上記のように、あらかじめ作ったdockerネットワーク
xdebug_networkなどを
docker-compose.ymlに指定するなどして
アプリと、DBとか、アドマイアなど、コンテナ同士で全部接続しておく

Xdebugのリモートデバッグのために、アプリだけ接続すればよさそうに思えるが
全コンテナしとかないとエラーで動かない






XdebugのUbuntuへのインストールや、設定

情報:
ローカル環境でXAMPP ( Macの人はMAMPか )
でWindowsだけでのphpの開発環境作ってる時のXdebugのインストールや
設定方法については、
ネット上に情報が、既に沢山あると思いますので、それは割愛します。
ここで情報として書いてるのは、docker-compose.ymlとDockerfileを使った
LAMPなどのイメージでのdockerを使った開発で、Xdebugを使う時にどうするのか
ということに焦点をあてて書いてます。
何が書かれているのか、意味がわからなければ、まず、
XAMPPでのローカルでWindowsだけでのphpの開発環境作ってる時の
Xdebugのインストールや設定方法のところから
やり方を調べて、そこの基礎知識を理解してから再度、読んでいただければ
よろしいかと思います。

dockerを使った状態で、Xdebugを使うと
dockerコンテナとホストのリモートでリモートデバッグになるから
その通信路をdocker-compose.ymlで設定する必要がある。
事前に定義したdockerネットワークを用いて、通信路の設定を行う。
上述のxdebug_networkを使うイメージで、
が、dockerが自動的に使用するデフォルトのブリッジネットワークでよいので、
networksセクションの設定の記述は不要です。
ただし、アプリのコンテナにenvironmentセクションでXdebug用の設定を
記述する必要があります。

アプリのコンテナには、下記のものを追加する。

   environment:
     XDEBUG_MODE: debug
     XDEBUG_CONFIG: "client_host=host.docker.internal client_port=9003"
**ここなくてもよい   networks:
**ここなくてもよい     - xdebug_network

他のDBとか、アドマイアのコンテナには、

**これは不要   networks:
**これは不要     - xdebug_network

を各々追加して
docker-compose.ymlの一番下に

**これは不要   networks:
**これは不要     xdebug_network:
**これは不要       external: true

を追加しておく



php.iniには、

zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20190902/xdebug.so
xdebug.mode=debug
xdebug.start_with_request=yes
xdebug.client_host=host.docker.internal
xdebug.client_port=9003
xdebug.log=/tmp/xdebug.log

を追加するのであるが、

/usr/local/lib/php/extensions/no-debug-non-zts-20190902/xdebug.so

は、dockerコンテナ側で使ってるphpのバージョンによって異なる
それは、Xdebugのwizardのサイトで確認することになる

Xdebug自体は、

pecl channel-update pecl.php.net

をやってから

pecl install xdebug-3.1.6

をやってインストールする
ただし、上記の例のxdebug-3.1.6の「3.1.6」の部分などは、
何にするかは、phpinfo()の内容をXdebugのwizardのサイトに貼り付けて確認する

https://xdebug.org/wizard
↑、が、「Xdebugのwizardのサイト」でphpinfo()をした結果ブラウザに表示された内容を
このサイトのテキストボックスに貼り付けて「Analyse my phpinfo() output」のボタン
を押すと、インストールすべきXdebugのバージョンや、インストール方法の案内が表示される

ただし、Xdebugのwizardのサイトで表示されたインストールの方法は、
C/C++のソースコードをmakeでコンパイル／リンクしていく方式で
xdebug.soを作ってそれを所定の場所に持っていくような
インストール方法でやり方が書かれている。
その方法は難しいため、「Xdebugのwizardのサイト」では、
xdebug-3.1.6の「3.1.6」の部分などのバージョンだけの確認にとどめる。
そして、
実際のインストールは上記のpeclを使ったコマンドで行うのがよいだろう。
そして、その「pecl install xdebug-X.X.X」でインストールした時の
コンソールに出力されたログの最後のほうに表示内容から
/usr/local/lib/php/extensions/no-debug-non-zts-20190902/xdebug.so
の部分をコピペする形で、php.iniに記述する。

そして、VisualStudioCodeのほうの
./vscode/launch.json
は、下記のようにする

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for Xdebug",
            "type": "php",
            "request": "launch",
            "hostname": "0.0.0.0",
            "port": 9003,
            "pathMappings": {
                "/var/www/html/example_app": "${workspaceFolder}"
            }
        }
    ]
}

上記の
"/var/www/html/example_app"
の部分は、
ローカルのgitリポジトリをバインドマウントしたときに、
.gitがあるリポジトリのルートのディレクトリについて、
コンテナ側のパスだと何になるかのパスの値を指定する
dockerイメージがLAMPのイメージをベースにしていたら、
/var/www/html/からはじまるようなパスだったりすると思われる。

https://marketplace.visualstudio.com/items?itemName=xdebug.php-debug
↑のプラグインをVisualStudioCodeへインストールする必要があると思う。





ide-helperのインストールおよび、設定

＜なんのためにするのか＞
Ubuntuとは直接関係ない話かもしれないが。

Laravelが動的に解決しているものについて

VisualStudioCodeの静的解析ツール「PHP Intelephense」が

静的に解決できない問題を解消したい。

そのため、実行には影響を与えないメタ情報のコードを出力する。

実行には影響を与えないメタ情報のコードを、

VisualStudioCodeが読み込むことでLaravelが動的に解決している

事柄を静的解析ツール「PHP Intelephense」のプラグインが、

静的に解決できるようになる。

そのことを通じて、

正味、実行時にエラーになる個所だけエディタ上で

怒ってくれるような環境や、コーディング時の入力補完が

ある程度、効いてくれるような環境を目指す。

例として、Laravelでエイリアス定義しているものは、

use文を書かなくても実行時にはエラーにならないから

静的解析ツールで怒ってほしくない

また、use文で書いてないそのようなエイリアスでも

静的解析ツールでの入力補完が効くようにしたりになったり

してほしいからである。

https://github.com/barryvdh/laravel-ide-helper
がide-helperの本家の場所

まず、

php artisan --version

でLaravelのバージョンを確認してください

php -v

でphpのバージョンを確認してください
その情報を見て、下記のどちらのコマンドを実行するか
決定してください

Laravelのバージョン: 10および11の場合
( PHP 8.1以上の場合。Laravel 10、11は、PHP 8.1以上である必要がある )

composer require --dev barryvdh/laravel-ide-helper:^3.0

Laravelのバージョン: 6.x、7.x、8.x、および9.x
( PHP 7.2以上の場合。
Laravel 6.xおよび7.xは、最低でもPHP 7.2が必要
Laravel 8.xはPHP 7.3以上
Laravel 9.xはPHP 8.0以上
)

composer require --dev barryvdh/laravel-ide-helper:^2.0



上記よりも、Laravelやphpのバージョンが低い場合は、
ide-helperは対応しません。（　残念ながら )


これは、dockerコンテナ内などで、ローカルのgitリポジトリのルートディレクトリで実行する

その後、下記のコマンドで
メタ情報のファイルを出力する


１）

php artisan ide-helper:generate

このコマンドで、
プロジェクトのルートディレクトリに
_ide_helper.php
が出力される。
すべてのファサードとエイリアスに関するメタデータが含まれます。
アプリの実行には影響がない
このファイルがあることで、「PHP Intelephense」が静的に理解できるようになる。


２）

php artisan ide-helper:models --nowrite

★こちらのコマンドは.envでのDB接続情報を通じてDBアクセスできる状況で★
★MySQLなどのDBのコンテナなどが起動中の時にコマンドを打たたないと正常に動きません★
このコマンドで、
モデルクラスを読み取って
Eloquentモデルに関するメタデータを含む
_ide_helper_models.php
を出力する
「PHP Intelephense」が静的に理解できるようになるためのものだと思われる。


３）

php artisan ide-helper:meta

このコマンドで、
プロジェクトのルートディレクトリに
.phpstorm.meta.php
が出力される。
これは、VisualStudioCodeのようなIDEで「PHPStorm」というものがあり
「PHPStorm」での機能と同様のことをVisualStudioCodeでもできるようにするためのプラグインの
PHPStorm Formatter
PHPStorm Snippets
などを利用するときに役に立つ
PHPStorm用のメタ情報が含まれてるようです。


４）

php artisan ide-helper:eloquent

これを打ち込むと
～/vendor/laravel/framework/src/Illuminate/Database/Eloquent/Model.php
だけ1ファイルのヘッダーのコメントだけ、少しだけ追記される
Eloquentを使った実装時の入力補完などに役立つかもしれない

下記で、静的解析ツール用のメタ情報を出力したら
.git/info/exclude
( 個人別、無視リストに下記のように追加しておく )

/artisan
/.vscode
/_ide_helper.php
/.phpstorm.meta.php
/_ide_helper_models.php

ただし、この設定をしてもgitbashや、sourcetreeでは差分としてあがってファイルもある。
（理由は、知らない)
その件の対処法については、
後述の目次の項目の「.git/info/exclude (個人別無視リスト)の補足事項」を参照のこと。

/artisanは、ide-helperのインストールで、artisanのバイナリファイルが
更新されるようで、
sourcetreeや、gitのツールによっては差分としてあがってきてしまうことがあり
これを防ぐため
artisanのバイナリファイルをプッシュする必要などないと思うため
無視リストの追加でよい
/.vscodeは、launch.jsonなどの変更分が差分にあがらないようにするため

/_ide_helper.php
/.phpstorm.meta.php
/_ide_helper_models.php
については、上記のide-helperのコマンドで出力された
メタ情報なので、個人別無視リストに追加しておく

静的解析ツールをチーム内で使わない人もいたりする
その人たちには関係のない話なので
自分の個人だけ無視リストに追加しておけばよい。

だいたい、一度、設定しとけば、以後はやる必要はない
ただ、
２）

php artisan ide-helper:models --nowrite

★こちらのコマンドは.envでのDB接続情報を通じてDBアクセスできる状況で★
★MySQLなどのDBのコンテナなどが起動中の時にコマンドを打たたないと正常に動きません★
こちらについては、DB設計など、テーブルの構成が変わり
モデルクラスの実装がチーム全体で変わっていくこともあるため
時々、実行して最新化しておくのがよいと思います

以上




.git/info/exclude (個人別無視リスト)の補足事項

上記にて、.git/info/exclude (個人別無視リスト)に

/artisan
/.vscode
/_ide_helper.php
/.phpstorm.meta.php
/_ide_helper_models.php

を追加する件について記載した。
これをすると、
Ubuntu(WSL2)のgitに関しては、素直に反応して
git statusコマンドを打ち込んだ時に差分としてあがってこない
また、GitKrakenでも差分として表示されない

補足:
これを書いていた段階では、そうでしたが、
その後、別件で、「Ubuntu(WSL2)のgit」や、「GitKraken」でも
.git/info/exclude (個人別無視リスト)に登録しているものが
差分としてあがってくることがありました。
ですので、関係ないです。
タイミングの問題で、git側のキャッシュの諸事情などで起こる現象です。
で、そのgit側のキャッシュのクリアは現時点ではおススメしてない
その件は、この目次項目の一番下に注意事項として書いてます。



しかしながら、
sourcetreeとgitbashでは、この
.git/info/exclude (個人別無視リスト)
に登録すると、登録したファイルの多くは差分としてはあがってこないが、
登録されているのにも関わらず、差分としてあがってきやがるファイルがある
理由は不明である。
( Ubuntu領域をwindows用のパスで見てるなどの変換とかの影響でバグってそうなるのか？ )

しかし、それは、gitbash上で下記のコマンドを打ち込むと
gitbashでgit statusで差分としてあがってこなくなる
sourcetreeは内部的にgitbashを利用しているようなので
連動して、sourcetreeでも差分としてあがってこなくなる

git update-index --assume-unchanged ファイルのパス

で、強制的に差分として挙がらないようにできるとのこと
その「強制的に差分として挙がらないようする」を解除するのが

git update-index --no-assume-unchanged ファイルのパス

とのこと
「no-」が余分にあります。( 「強制無視の解除って」意味で、2重否定のようでわかりにくいですけど )

それで、ide-helperをインストール時に実際にartisanのバイナリファイルが更新されて
Ubuntu(WSL2)のgitや、Gitkrakenでは、.git/info/exclude (個人別無視リスト)に従って
素直に差分から消えたが
gitbashや、sourcetreeでは差分にartisanのバイナリファイルが残る現象があった
（　なぜ？　とか、理由は知らない )

git update-index --assume-unchanged artisan


.git/info/exclude (個人別無視リスト)の時と異なり、artisanの先頭に/記号が付いてないことに注意
通常の相対パスでの指定です。

のコマンドをgitbashで実行することで、
gitbashや、sourcetreeでも、差分としてあがらないようにできた

解除するのは、

git update-index --no-assume-unchanged artisan

と「no-」が余分にあるのを実行するとのことだが、これは試したことがない
実行すると強制無視が解除され差分としてあがってきます。





久々にJavaをやるときの覚書

以前、Javaの開発を久々にやった時に
eclipse上の下記の設定が思い出せずに、
それを思い出しなおすまでの
数日間、作業効率が下がってしまったことがあったので
そんなことが無いように、ここにメモっておくことにした

★★★★★★★★
★★ その１ ★★
★★★★★★★★
ソースコードは、
Ctrl + Shift + r
で起動した窓で
ソースコード名の部分一致検索での
インクリメンタルが検索できる
★★★★★★★★
★★★★★★★★

★★★★★★★★
★★ その２ ★★
★★★★★★★★
ビルドパスが設定されている
.jarの内部や、.classなどの
コンパイル済みのクラスは、
Ctrl + Shift + t
で起動した窓で
クラス名の部分一致検索での
インクリメンタルが検索できる
★★★★★★★★
★★★★★★★★

★★★★★★★★
★★ その３ ★★
★★★★★★★★
ツリービューの上部にある
→
←
「ボタンのエディタにリンク」のトグルボタンを押しこんで有効にしておく

開いているソースコードに連動して、ツリービューが該当のものが選択状態になる
★★★★★★★★
★★★★★★★★

★★★★★★★★
★★ その４ ★★
★★★★★★★★
ウィンドウ - ビューの表示 - その他

で、
progress
と入力し、検索結果の
進行状況　のビューを、
のタブ表示に追加しておくのがよい

問題
と入力し、検索結果の
問題　のビューを、
のタブ表示に追加しておくのがよい

表示 または、Debug Shell
と入力し、検索結果の
表示　のビュー
まはた
Debug Shell　のビュー
のタブ表示に追加しておくのがよい

eclipseだと「表示」ビュー、STSだと「Debug Shell」ビューなど
eclipseの亜種がいろいろあり、名称が異なるが、機能は同じビューである。
★★★★★★★★
★★★★★★★★

★★★★★★★★
★★ その５ ★★
★★★★★★★★
ビルド方式として、Gradleを使っているケースは、
プロジェクトを右クリして、
Gradle - Gradleプロジェクトのリフレッシュ
をする必要があったりする
いつも、必要ではないが
通常のビルトとは別にそれも
をしないと、初期のビルドや、
何かの実装の変更時などで
ビルドエラーが消せないことがある
ということだけ、心得ておくこと
★★★★★★★★
★★★★★★★★

Ubuntu(WSL2)でjavaを使えるようにした時のメモ

sudo apt update
sudo apt install default-jdk

$ java -version
openjdk version "21.0.4" 2024-07-16
OpenJDK Runtime Environment (build 21.0.4+7-Ubuntu-1ubuntu224.04)
OpenJDK 64-Bit Server VM (build 21.0.4+7-Ubuntu-1ubuntu224.04, mixed mode, sharing)

Extension Pack for Java v0.29.0
をVisualStudioCodeに入れたら
VisualStudioCodeで動かせた
複雑なことをしたかったわけでなく
以前、ソースコードの状況を比較したりする
ツールを個人的にjavaで作っててそれがが動けばよし
だったので、一旦、現時点では、これ以上の深追い調査はしない。

Node.jsとnpm

npm i
を打ち込んだら、エラーが連発し、
which npm
で確認したら、Windows側にインストールしたNode.js見に行ってて
そりゃ、エラーなるよ
ということだった。

なので、Ubuntu側にもインストールする
PATH変数はUbuntu側が優先的な値のため
Ubuntuにも入れたら、そっちを見に行ってくれる

別件 Node.jsのインストール、( npm コマンドが使いたかった )

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -

をやってから

sudo apt install nodejs -y

をする

node -v
と
npm -v

で、確認する

例）

$ node -v
v22.6.0
$ npm -v
10.8.2






Node.jsとnpmはnodebrewでインストールしたほうがよい

1つ上の「Node.jsとnpm」を書いてた時に、直でインストールしていた

$ node -v
v22.6.0
$ npm -v
10.8.2

$ which node
/usr/bin/node
$ which npm
/usr/bin/npm

を一旦、削除してから、
nodebrewで同じバージョンのNode.jsとnpmを入れなおす方向性で作業しました。
その作業のついでに、この目次項目の記事を書くことにしました。

直でインストールしたものなので、
sudo apt-get remove --purge nodejs npm
下記のコマンドで普通に削除します

$ sudo apt-get remove --purge nodejs npm
[sudo] password for 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package 'npm' is not installed, so not removed
The following packages will be REMOVED:
  nodejs*
0 upgraded, 0 newly installed, 1 to remove and 81 not upgraded.
After this operation, 219 MB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 49912 files and directories currently installed.)
Removing nodejs (22.6.0-1nodesource1) ...
Processing triggers for man-db (2.12.0-4build2) ...

$ node -v
-bash: /usr/bin/node: No such file or directory
$ npm -v
-bash: /usr/bin/npm: No such file or directory
$
$ which node
$
$ which npm
/mnt/c/Program Files/nodejs//npm
$

nodeは、not foundで
npmは、Ubuntu(WSL2)のものはなくなり、環境変数PATHの後ろのほうに指定してる
Windows側のものがwhichコマンドででてくるような状況になりました。

なお、
sudo apt-get remove --purge nodejs npm
--purge は、
関連する設定ファイル（/etc/ディレクトリなどに保存されている設定情報）も全て削除します。
システムにNode.jsやnpmに関する痕跡を残さないために、完全なクリーンアップ
の意味だそうです。




ここからは、nodebrewでのNode.jsとnpmのインストール

https://github.com/hokaccha/nodebrew

のサイトに行き、nodebrewのインストール方法を見る

nodebrewは、一般ユーザでインストールするので
rootになって作業したり、sudoを使って作業はしない

curl -L git.io/nodebrew | perl - setup
を実行する

$ curl -L git.io/nodebrew | perl - setup
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0
100 26039  100 26039    0     0  10950      0  0:00:02  0:00:02 --:--:--   99k
Fetching nodebrew...
Installed nodebrew in $HOME/.nodebrew

========================================
Export a path to nodebrew:

export PATH=$HOME/.nodebrew/current/bin:$PATH
========================================
$

最後に出力された

export PATH=$HOME/.nodebrew/current/bin:$PATH

を
~/.bashrc
や
~/.zshrc
や
~/.profile
などログイン時に実行されるシェルに追記したあと
( 開発端末など、開発作業するユーザが１つと決めてるならば
~/.profileに追記しておけば、使ってるシェルが変わっても継続反映できて便利だろう )

source ~/.bashrc
や
source ~/.zshrc
や
source ~/.profile
などで、上記の追記したものを
再読み込みする（または、ターミナルの起動からやり直す)

nodebrew -v
を打ち込む
下記のように出力されたら、nodebrew自体のインストールはできている

$ nodebrew -v
nodebrew 1.2.0

Usage:
    nodebrew help                         Show this message
    nodebrew install <version>            Download and install <version> (from binary)
    nodebrew compile <version>            Download and install <version> (from source)
    nodebrew install-binary <version>     Alias of `install` (For backward compatibility)
    nodebrew uninstall <version>          Uninstall <version>
    nodebrew use <version>                Use <version>
    nodebrew list                         List installed versions
    nodebrew ls                           Alias for `list`
    nodebrew ls-remote                    List remote versions
    nodebrew ls-all                       List remote and installed versions
    nodebrew alias <key> <value>          Set alias
    nodebrew unalias <key>                Remove alias
    nodebrew clean <version> | all        Remove source file
    nodebrew selfupdate                   Update nodebrew
    nodebrew migrate-package <version>    Install global NPM packages contained in <version> to current version
    nodebrew exec <version> -- <command>  Execute <command> using specified <version>
    nodebrew prune [--dry-run]            Uninstall old versions, keeping the latest version for each major version

Example:
    # install
    nodebrew install v8.9.4

    # use a specific version number
    nodebrew use v8.9.4
$

公式サイトにいろいろと書いてて、見つけにくいが
nodebrew install-binary
でインストールするのがオススメとされている

nodebrew install-binary では、ビルド済みのバイナリをダウンロードするだけなので、
ソースからビルドする場合に必要な make、gcc、g++ などのビルドツールが不要です。
これにより、インストールに際して余計なパッケージを追加する手間が省け、
システムをシンプルに保つことができます。

ソースからビルドする場合、環境依存のエラーや、ビルドツールのバージョンによる互換性問題が発生することがありますが、
install-binary は既にビルドされているため、こうしたエラーが発生しにくいです。
結果として、より安定して確実にインストールが完了します。

通常は、

nodebrew install-binary latest
(最新版)のインストール
や
nodebrew install-binary stable
(安定版の中での最新版)のインストール

でインストールするとのこと

ここでは、(この文章を書いてる時点では)
先ほどnodebrewでない方式でインストールしてて、削除した
メモしていたバージョンの復活のため

nodebrew install-binary v22.6.0

を実行することにした

$ nodebrew install-binary v22.6.0
Fetching: https://nodejs.org/dist/v22.6.0/node-v22.6.0-linux-x64.tar.gz
########################################################################################################################################################################################################## 100.0%
Installed successfully

その後

$ node -v
Command 'node' not found, but can be installed with:
sudo apt install nodejs
$ npm -v
10.8.2
$

となった
Node.jsは、v22.6.0を
nodebrew install-binary v22.6.0
で、インストールしたはずなのに、
node -v は、not found

npm -vは、対応するnpmのバージョン10.8.2
が使える状況となっている

なぜ、node -v はnot foundか？

nodebrew ls
で、インストール済のNode.jsのバージョンを表示できる

$ nodebrew ls
v22.6.0

current: none

current: none となってる状況では
なにも、選択状態になっていない

だから、node -v はnot foundになるのである

nodebrew use v22.6.0
を打ち込むと

今度は下記のようになった

$ nodebrew use v22.6.0
use v22.6.0

$ nodebrew ls
v22.6.0

current: v22.6.0

$ node -v
v22.6.0
$ npm -v
10.8.2
$

$ which node
/home/myuser/.nodebrew/current/bin/node
$
$ which npm
/home/myuser/.nodebrew/current/bin/npm
$

これで使える
なお、
nodebrew install-binaryで、node.jsをインストールすると
対応するバージョンのnpmもインストールしてくれるようだ

nodebrewは、node.jsのバージョンをnodebrew useで切り替えると
環境にnpmがあれば、切替先のnode.jsにあったバージョンのnpmに切り替えもしてくれるとのことだ

これで、

nodebrewを使う前に、入れてたバージョンと同じ
node.jsと、npmがそろったので

nodebrewを使う前のnode.jsと、npmのときに作った環境のプロジェクトフォルダを
VisualStudioCodeで開いて
npm run dev
npm run build
npm run preview
などが動くことが確認された

＜おまけ＞
nodeと打ち込んだら、nodeのプロンプトが打てる状況となる
そこでhello worldしてる例

$ node
Welcome to Node.js v22.6.0.
Type ".help" for more information.
>
> console.log('hello world')
hello world
undefined
>
>
(To exit, press Ctrl+C again or Ctrl+D or type .exit)
>


Typescriptのトランスパイルをするためviteのインストール方法

インストールしたいフォルダにcdコマンドで移動する

code .

にて、そのフォルダで、VisualStudioCodeを移動する。

以下、VisualStudioCode内のターミナル上での作業を行う

npm create vite@latest

どこにインストールか聞かれるので、

.

とだけ打ち込んでエンターキーを押す
あらかじめインストールしたいフォルダにcdコマンドで移動しているためそれでよい

Select a framewarod:
と表示され
Vanilla
Vue
React
Lit
Svelte
Solid
Qwik
Others
の選択肢が出てくる
Vanillaを選択するとframeworkなし

その後、
TypeScript
Javascript
を選択するようになっているが、そこで
TypeScript
を選択する

ここまでの流れは、下記のようなコンソールログとなる

$ npm create vite@latest
Need to install the following packages:
create-vite@5.5.2
Ok to proceed? (y) y


> npx
> create-vite

✔ Project name: … .
✔ Select a framework: › Vanilla
✔ Select a variant: › TypeScript

Scaffolding project in /udemydir/ts_jik/test...

Done. Now run:

  npm install
  npm run dev

npm notice
npm notice New patch version of npm available! 10.8.2 -> 10.8.3
npm notice Changelog: https://github.com/npm/cli/releases/tag/v10.8.3
npm notice To update run: npm install -g npm@10.8.3
npm notice

npm install
を実行する

$ npm install

added 6 packages, removed 43 packages, changed 6 packages, and audited 12 packages in 7s

3 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

npm run dev
を実行する

$ npm run dev

> test@0.0.0 dev
> vite


  VITE v5.4.3  ready in 251 ms

  ➜  Local:   http://localhost:5173/
  ➜  Network: use --host to expose
  ➜  press h + enter to show help

Vite + Typescript
と書かれたwebページが、

http://127.0.0.1:5173/

でブラウザ起動する形となる

Typescriptに必要な設定ファイルや、フォルダが一通り出来上がるため
srcフォルダの下に

*.tsのファイルを作りTypescriptの実装が行える状況となる

Vue.jsの環境を作る例

https://www.youtube.com/watch?v=Oyr0sr6l3SQ&t=46s
の動画を参考に、vue.jsの環境を作ったときのメモ書き

前述の目次項目では、先にフォルダを作成し
そのフォルダ内へcdコマンドで移動してから
インストール作業をして、Project nameのところで、. を打ち込む方式
だったが、vue.jsのとき、そのやり方だとエラーになってうまくいかなかったため
ひとつ上のフォルダで、インストール作業をして、
Project nameのところで、vue-lesson のフォルダ名を打ち込んだ

npm create vue@latest

$ npm create vue@latest

> npx
> create-vue


Vue.js - The Progressive JavaScript Framework

RangeError: Incorrect locale information provided

✔ Project name: … vue-lesson
✔ Add TypeScript? … No / Yes
✔ Add JSX Support? … No / Yes
✔ Add Vue Router for Single Page Application development? … No / Yes
✔ Add Pinia for state management? … No / Yes
✔ Add Vitest for Unit Testing? … No / Yes
✔ Add an End-to-End Testing Solution? › No
✔ Add ESLint for code quality? … No / Yes
✔ Add Prettier for code formatting? … No / Yes
✔ Add Vue DevTools 7 extension for debugging? (experimental) … No / Yes

Scaffolding project in /udemydir/vue-lesson...

Done. Now run:

  cd vue-lesson
  npm install
  npm run format
  npm run dev

npm install

$ npm install
npm warn deprecated inflight@1.0.6: This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful.
npm warn deprecated @humanwhocodes/config-array@0.11.14: Use @eslint/config-array instead
npm warn deprecated rimraf@3.0.2: Rimraf versions prior to v4 are no longer supported
npm warn deprecated glob@7.2.3: Glob versions prior to v9 are no longer supported
npm warn deprecated @humanwhocodes/object-schema@2.0.3: Use @eslint/object-schema instead

added 150 packages, and audited 151 packages in 2m

33 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

npm run format

> vue-lesson@0.0.0 format
> prettier --write src/

src/App.vue 197ms (unchanged)
src/assets/base.css 42ms (unchanged)
src/assets/main.css 44ms (unchanged)
src/components/HelloWorld.vue 92ms (unchanged)
src/components/icons/IconCommunity.vue 31ms (unchanged)
src/components/icons/IconDocumentation.vue 16ms (unchanged)
src/components/icons/IconEcosystem.vue 19ms (unchanged)
src/components/icons/IconSupport.vue 9ms (unchanged)
src/components/icons/IconTooling.vue 11ms (unchanged)
src/components/TheWelcome.vue 47ms (unchanged)
src/components/WelcomeItem.vue 36ms (unchanged)
src/main.js 10ms (unchanged)

★上記までのコマンドは、VSコードのターミナルで実行するより、Ubuntus(WSL2)のターミナルで実行するほうが安定していた★

その後、
Project nameのところで、vue-lesson のフォルダ名に、
cdコマンドで移動した後、
code .
でVSコードを起動して
VSコード内のターミナルで

npm run dev
で、vite経由で

http://127.0.0.1:5173/

での初期画面を起動した

npm run dev
でviteを起動しながら、開発作業をすると、ホットデプロイのような形で
ソースコードの修正と同時にローカル動作に反映される

npm run buid
を行うと、distフォルダに静的にvue.jsの内容がjavascriptのみの形に変換された
静的なコードになる

npm run preview
は、distフォルダに出力された内容での動作を見るための
ローカルサーバーを起動するコマンドのようである

npm run lint
は、Linter

npm run format
は、コードのフォーマット

.vscode/extensions.json

{
  "recommendations": [
    "Vue.volar",
    "dbaeumer.vscode-eslint",
    "esbenp.prettier-vscode"
  ]
}

は、おススメの拡張機能
これを入れると効率がよい

.eslintrc.cjs
の

  'extends': [
    'plugin:vue/vue3-essential',
    'eslint:recommended',
    '@vue/eslint-config-prettier/skip-formatting'
  ],

の
'plugin:vue/vue3-essential',
は、
'plugin:vue/vue3-recommended',
にして

  'extends': [
    'plugin:vue/vue3-recommended',
    'eslint:recommended',
    '@vue/eslint-config-prettier/skip-formatting'
  ],

にしておくのがよい

Discussion