Visual Studio Codeを使ってRasPi Zero 2WにSSH接続して作業しています。このとき、Byobuを自動起動させるのに手間取ったのでメモとして残しておきます。
ByobuについてはImpress PC Watchの記事「SSH使うなら、これだけは覚えておきたい話」に解説されています。このソフトは多機能なテキストスクリーン・マネージャーですが、回線切断時にセッションを保持し、再接続時にセッションを再開させる機能を持っています。SSH接続のような回線品質だのみの作業には心強い味方です。以前同様なソフトとしてscreenを使ったことがありますが、Byobuはscreenのラッパーだそうです。
Byobuを使うことで、作業の心理負担が軽くなります。例えば、サーバーで長い時間がかかる作業を行う際は、作業を投入した後に無造作にVS Codeを閉じて構いません。再度VS Codeを起動してSSH接続すると、継続していた作業をByobuから見ることができます。
さて、Byobuにはリンク先に解説されているようなログイン時の自動起動機能があります。回線切断からの保護を目的に使うので、ログイン時の自動起動は理にかなっています。そこで手元で試してみたのですが、妙な挙動に気付きました。
- Windowsのcommand prompt (cmd) からSSH接続するとByobuが自動起動する。
- Visual StudioのterminalからSSH接続するとByobuが自動起動しない。
これは妙です。Twitterでつぶやいたところ、参考になりそうなページを教えていただきました。
調査の結果判明したのは
- Windowsのcommand prompt (cmd) からSSH接続するとログインシェルが起動する。
- Visual StudioのterminalからSSH接続するとログインシェルではない対話型シェルが起動する。
ということです。Byobuの自動起動は~/.profileに設定されています。~/.profileはログインシェルからしか読み込まれないため、ここに挙げた問題が発生していたのでした。調べてみると、「VS Codeのターミナル接続がログインシェルとしてふるまわない」問題はVS CodeのIssueとして2019年に登録されています。
明らかなバグに思えるのですが、開発者はすでにある使用例との互換性を気にして修正を渋っているようです（つまりバグが仕様になりつつある）。結果的に上のIssueにバッドノウハウが集積することになっています。
話が長くなりましたが、この問題は以下の設定をVS Codeのsettings.jsonに追加すると解決します。
"terminal.integrated.defaultProfile.linux": "bash",
"terminal.integrated.profiles.linux": {
"bash": {
"path": "bash",
"args": [
"-l"
]
}
},
この設定では、Linuxにターミナル接続する場合、bashをシェルとして引数に”-l”を渡しています。”-l”を渡すとbashはログインシェルとして動作します。
この設定追加で、VS CodeによるSSH接続先のRasiP Zero 2W ( Ubuntu Server )でもByobuがSSH接続時に自動起動するようになりました。