WSL2 の環境で python コマンドが使えたり使えなかったりする謎について

前々から、 WSL2 で python を使う時は pyenv + venv で python 環境を扱っています。

さて、わざわざプロジェクトフォルダを作ったうえで、

pyenv local 3.xx

のようにバージョンを指定せずに使いたい時も結構あります。そのようなときに、 python を起動しようとすると

mor@DESKTOP-DE7IL4F:~$ python
pyenv: python: command not found

The `python' command exists in these Python versions:
  3.11.4
  3.13.1

Note: See 'pyenv help global' for tips on allowing both
      python2 and python3 to be found.
mor@DESKTOP-DE7IL4F:~$

のようになることがあります。でも、場合によっては python でちゃんと起動できるときもあります。

この動作がちょっと気持ち悪かったので、何が問題なのか調べてみました。

問題を把握

さて、うまくいく時といかない時にどのような違いがあるのか、いろいろと試してみると

mor@DESKTOP-DE7IL4F:~/tmp/no_python_version$ pyenv version
system (set by /home/mor/.pyenv/version)
mor@DESKTOP-DE7IL4F:~/tmp/no_python_version$

のようにシステムの python を使うとなっているフォルダで発生していました。

一方、 pyenv local でバージョンを指定したフォルダの場合は、

mor@DESKTOP-DE7IL4F:~/tmp/exist_python_version$ pyenv version
3.13.1 (set by /home/mor/tmp/exist_python_version/.python-version)
mor@DESKTOP-DE7IL4F:~/tmp/exist_python_version$ python --version
Python 3.13.1
mor@DESKTOP-DE7IL4F:~/tmp/exist_python_version$

のように期待通りに動いています。どういうことだ？

このままだとわからないので python の本体がどこにあるか調べてみます。

mor@DESKTOP-DE7IL4F:~/tmp/exist_python_version$ which python
/home/mor/.pyenv/shims/python
mor@DESKTOP-DE7IL4F:~/tmp/exist_python_version$

pyenv の環境内ですね。pyenv 指定がないほうも、

mor@DESKTOP-DE7IL4F:~/tmp/no_python_version$ which python
/home/mor/.pyenv/shims/python
mor@DESKTOP-DE7IL4F:~/tmp/no_python_version$

同じですね。というか、 pyenv によりこのファイルを呼び出すようになっているんですよね。

pyenv の動作

ということで改めて pyenv の動作を確認してみます。

pyenvはどのようにバージョンを切り替えているのか? #Python - Qiita

こちらのブログの記事などを読むとわかりやすかったです。雑にまとめると

PYENV_VERSION 環境変数 ---> ローカルにある .python-version ファイル ---> 親ディレクトリの .python-version ファイル ---> global の設定値 ---> sysytem

という順で決まるそうです。pyenv version での表示と一致しているし、へんな感じじゃないですね。

解決

ふと思い出したのですが、 python って python2 とか python3 とかで起動することもありますよね。あれっていつ頃から python で python3 を起動するようになったんだろうか？と思い立って調べてみると、なんと、いまの Ubuntu (24.04) とかには python3 のみがインストールされていて python は入っていないとのことです。

Ubuntuで「python」コマンドが見つからない理由と解決方法 | LFI

で、昔は python2 と python が入っていて、 python が python2 を指していたとのこと。

しかも、いまは python で python3 を起動したければ、自分でaliasを張ったり、 python-is-python3 パッケージというのをインストールするという方法をとるそうです。

あ、きっとこれですね。おぼろげながら使っているんで、いろんな記憶がごちゃまぜになって、 python コマンドが普通にあると思ってました。

というわけで、pyenv をインストールすると、

• ~/.pyenv/shims に python がインストールされる
• pyenv local でバージョンが割り当てられているる場合は、そちらの python が呼び出される
• system の場合も同様
• でも、システムには python コマンドがない

という流れのような気がします。実際 pyenv でインストールしたほうの python を見てみると

mor@DESKTOP-DE7IL4F:~/.pyenv/versions/3.13.1/bin$ ls -l python*
lrwxrwxrwx 1 mor mor    10 12月 12  2024 python -> python3.13
lrwxrwxrwx 1 mor mor    17 12月 12  2024 python-config -> python3.13-config
lrwxrwxrwx 1 mor mor    10 12月 12  2024 python3 -> python3.13
lrwxrwxrwx 1 mor mor    17 12月 12  2024 python3-config -> python3.13-config
-rwxr-xr-x 1 mor mor 17704 12月 12  2024 python3.13
-rwxr-xr-x 1 mor mor  3339 12月 12  2024 python3.13-config
-rwxr-xr-x 1 mor mor 70581 12月 12  2024 python3.13-gdb.py
mor@DESKTOP-DE7IL4F:~/.pyenv/versions/3.13.1/bin$

のように ~/.pyenv/versions/（バージョン番号）/bin の配下に python がシンボリックリンクとして作られていました。

一方、システムの /usr/bin を見てみると、

mor@DESKTOP-DE7IL4F:/usr/bin$ ls -l python*
-rwxr-xr-x 1 root root    2640  8月  3  2024 python-argcomplete-check-easy-install-script
lrwxrwxrwx 1 root root      10 11月 12 21:15 python3 -> python3.12
lrwxrwxrwx 1 root root      17 11月 12 21:15 python3-config -> python3.12-config
-rwxr-xr-x 1 root root 8020928  1月  8 20:30 python3.12
lrwxrwxrwx 1 root root      34  1月  8 20:30 python3.12-config -> x86_64-linux-gnu-python3.12-config
mor@DESKTOP-DE7IL4F:/usr/bin$

となっており、 python はない状態です。

テスト

ということで、試してみます。

mor@DESKTOP-DE7IL4F:~$ sudo apt install python-is-python3

として、 python-is-python3 パッケージをインストールします。その後

mor@DESKTOP-DE7IL4F:~/tmp/no_python_version$ ls -laF
合計 8
drwxr-xr-x  2 mor mor 4096  1月 30 15:39 ./
drwxr-xr-x 22 mor mor 4096  1月 30 15:41 ../
mor@DESKTOP-DE7IL4F:~/tmp/no_python_version$ pyenv version
system (set by /home/mor/.pyenv/version)
mor@DESKTOP-DE7IL4F:~/tmp/no_python_version$ python --version
Python 3.12.3
mor@DESKTOP-DE7IL4F:~/tmp/no_python_version$

解決できましたね。念のために /usr/bin もみてみると

mor@DESKTOP-DE7IL4F:/usr/bin$ ls -l python*
lrwxrwxrwx 1 root root       7  6月 13  2023 python -> python3
-rwxr-xr-x 1 root root    2640  8月  3  2024 python-argcomplete-check-easy-install-script
lrwxrwxrwx 1 root root      10 11月 12 21:15 python3 -> python3.12
lrwxrwxrwx 1 root root      17 11月 12 21:15 python3-config -> python3.12-config
-rwxr-xr-x 1 root root 8020928  1月  8 20:30 python3.12
lrwxrwxrwx 1 root root      34  1月  8 20:30 python3.12-config -> x86_64-linux-gnu-python3.12-config
mor@DESKTOP-DE7IL4F:/usr/bin$

ちゃんと python が入っていました。

まとめ

ちょっとしたことですが、システムにデフォルトで python が入っていないということを知らなかったばっかりに、時間を費やしてしまいました。まずは一件落着です。

Netlify でホストしているサイトの証明書の更新に失敗

先日、 netlify から下記のようなメールが届きました。

SSL 証明書の更新に失敗したということのようです。

森ソフトのサイト は netlify でホストしています。で、もう結構長い間安定して運用していて、証明書関連のトラブルも特になったのでちょっと意外です。

このトラブルに対応した話を一応メモっておきます。

原因の確認

まずは、念のため netlify の設定画面で確認してみると

と表示されています。メールの内容と同じですね。失敗した理由として

missing domains mori-soft.com

となってます。

netlify の設定を行ったのはずいぶんと前だったので、当時のブログ記事を読み返して思い出してみます。2018 年に作業したようですね。ずいぶんと前のことでしたが、一応、なんとなくなにやったか思い出せますね。

これを参考にしていまの設定内容を確認していくと、あれ？ mori-soft.com （ APEX ドメイン）の DNS レコードが netlify のロードバランサ―に向いてなくて、さくらインターネットのサーバーそのものを指していますね。

どういうことだっけ？何かの時にDNSレコード触ったっけ？

さくらの DNS だとある程度の過去のゾーン情報も追いかけられるので、一番古い 2024 年 5 月 16 日 を表示してみると、その時点で既にさくらインターネットのサーバーを指してますね。

Let's Encrypt の証明書の有効期限は 3 ヶ月ということなので、前回の更新は 2025 年 11 月頃に行っていると思われます（上記の画面もそうなってますね）。すくなくともこの一年近くは証明書の更新に関して何も言われなかったんだけど、なんでなんだろうか？

ちなみに、ちょっと調べると

Certificate renewal incomplete - Support - Netlify Support Forums

のような記事も見つかったので、最近、証明書の更新処理で何か変更が入った可能性もありますね。

修正

さて、DNS レコードが書き換えられた（自分で戻した？）理由はわかりませんが、そうはいっても、このままだと証明書の更新ができなくて困るので改めて設定しなおします。

作業前に念のため現在の Netlify のドキュメントを確認します。これが一番具体的ですかね。

Configure external DNS for a custom domain | Netlify Docs

いまも www を netlify でホストする時は APEX ドメインが netlify のロードバランサ―を指すように設定するとありますね。 では、早速やってみます。

さくらインターネットのDNSの管理画面を開いて、ゾーン情報の編集を選択しておきます。修正後はこんな感じになります。

なお、netlify でホストすると netlify のサブドメインが割り当てられるのですが、このサブドメインが netlify.com から netlify.app に変わったようなので、これも合わせて変更しておきます。

を

のように www の CNAME レコードを修正しました。

確認

手元の環境で dig mori-soft.com を引いたらロードバランサ―のアドレスが表示されるまでしばらく待ちます。

mor@DESKTOP-DE7IL4F:~$ dig mori-soft.com

; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> mori-soft.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37472
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mori-soft.com.                 IN      A

;; ANSWER SECTION:
mori-soft.com.          3600    IN      A       75.2.60.5

;; Query time: 40 msec
;; SERVER: 10.255.255.254#53(10.255.255.254) (UDP)
;; WHEN: Mon Jan 19 11:45:11 JST 2026
;; MSG SIZE  rcvd: 58

mor@DESKTOP-DE7IL4F:~$

こんな感じで無事に表示されるようになったら、さきほどの netlify のコンソール画面に戻って Renew Certificate を実行します。

最初は実行後も画面に変化がないのでちょっと不安でしたが、リロードしたらちゃんとこんな感じに表示されて、更新できたことが確認できました。

まとめ

にしても、 DNS レコードの件は謎ですね。ひとつありそうなのが、 2024 年の 2 月頃に DKIM/DMARC の設定を行っています。この作業はDNS の書き換えが発生するので、ひょっとしたら、さくらインターネット側で A レコードの内容を書き戻した可能性もありそうです。さくらインターネットのコンパネからメールの設定を変更すると振り分け設定が無効になったという過去の経験からの推測ですが。

もっとも、いまとなっては確かめようもありませんが。

なんにせよ、最近 netlify で証明書が更新できないといわれた方はご参考にしてみてください。

Windows 11 の WSL に Fortran をインストールして VSCode で開発する環境を整える

何十年ぶりになるか、ずいぶんと久しぶりに Fortran を使った仕事をすることになりました。学生時代以降 Fortran なんて触ったことなかったですが、まだまだ一部の業界では Fortran も現役なんですよねー。

仕事に先立ち、とりあえず手元の環境でも簡単な検証ができるように Fortran の開発環境を整えてみました。

ということで、昨今の Fortran 開発環境なども調べつつ、試したことをまとめておきます。

WSL に gfortran をインストール

まずは gfortran (GNU Fortran) をインストールしておきます。

mor@DESKTOP-DE7IL4F:~$ sudo apt install gfortran

インストールできていれば、バージョン情報がでます。

mor@DESKTOP-DE7IL4F:~$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/13/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 13.3.0-6ubuntu2~24.04' --with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-13 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-libstdcxx-backtrace --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-13-fG75Ri/gcc-13-13.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-13-fG75Ri/gcc-13-13.3.0/debian/tmp-gcn/usr --enable-offload-defaulted --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.3.0 (Ubuntu 13.3.0-6ubuntu2~24.04)
mor@DESKTOP-DE7IL4F:~$

コンパイルもしてみます。 FORTRAN 77 で書いてみます。

      PROGRAM HELLO
      PRINT *, "HELLO WORLD"
      END PROGRAM HELLO

懐かしの固定形式ですね。コンパイルして、実行します。

mor@DESKTOP-DE7IL4F:~/tmp/fortran$ gfortran test.f
mor@DESKTOP-DE7IL4F:~/tmp/fortran$ ./a.out
 HELLO WORLD
mor@DESKTOP-DE7IL4F:~/tmp/fortran$

実行できますね。

同じことを、自由形式の Fortran 90 でも試します。

program hello
    print *, "hello world"
end program hello

mor@DESKTOP-DE7IL4F:~/tmp/fortran$ gfortran test.f90
mor@DESKTOP-DE7IL4F:~/tmp/fortran$ ./a.out
 hello world
mor@DESKTOP-DE7IL4F:~/tmp/fortran$

こちらも問題なしですね。

VSCode の設定

WSL 上で Fortran コンパイラが動くようになったので、次は VSCode で開発できるようにします。

拡張機能もいろいろと紹介されていますが今回は下記の記事を参考にして、

VSCodeのFortran向け拡張を整理，最新化する（2022年6月） #VSCode-Extension - Qiita

下記１つだけインストールすることにしました。

Modern Fortran

ただ、『この拡張機能は拡張機能マーケットプレースによって署名されていません。』と表示されてて、インストールボタンが無効になっています。

少し調べてみると、以前にも同様の問題があったようで、

Can't install VSCode Modern Fortran - not signed by marketplace - #20 by Abhi_dev - Visual Studio Code - Fortran Discourse

こんなディスカッションもありました。公式の issues も見てみると

feat: Please sign the fortran-language vscode-extension on vscode market place · Issue #1200 · fortran-lang/vscode-fortran-support · GitHub

あー、既知の問題になってるようですね。次のメジャーアップデートでは解決されるようなので、現時点ではこの状態でインストールするしかなさそうです。

ということで、先ほどのディスカッションのところに載ってるように歯車アイコンをクリックして、

このメニューからインストールすることにします。すると、下記のように

警告が出ますが、『インストールする』を選択します。

再度確認を求められるので『発行元を信頼してインストールする』を押して進めば、問題なくインストールできます。

この状態で VSCode で先ほどのソースファイルを表示すると

おぉ、こんな感じにハイライトされるようになりました。

ツールのインストール

Modern Fortran の説明を読んでいくと、

• fortls
• findent
• fprettify

といった、言語サーバーや整形ツールを利用できるようになっているそうです。当初はこれらも一緒にインストールされるのかと思っていたのですが、 VSCode の画面の下部の通知を見ると、

と表示されているように、これらは自分でインストールする必要があるようです。

ただ、これらのツールは python 製のようでインストールは pip で行う必要があります。どこに入れようか少し迷うところではあるのですが、 Fortran の作業の時に Python のバージョンなどは考えたくないので、 pyenv / venv で指定した場所ではなく、システムの pip 環境に入れることにします。

ということで、インストールすると

mor@DESKTOP-DE7IL4F:~$ pip install fortls
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
    python3-xyz, where xyz is the package you are trying to
    install.

    If you wish to install a non-Debian-packaged Python package,
    create a virtual environment using python3 -m venv path/to/venv.
    Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
    sure you have python3-full installed.

    If you wish to install a non-Debian packaged Python application,
    it may be easiest to use pipx install xyz, which will manage a
    virtual environment for you. Make sure you have pipx installed.

    See /usr/share/doc/python3.12/README.venv for more information.

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.
mor@DESKTOP-DE7IL4F:~$

おっと、なんかエラーがでてきました。

調べてみると Python 3.12 以降はシステム領域に pip でパッケージをインストールすることが原則禁止になったようですね。そういや、最近は venv を使っているので、 Python 3.12 にアップデート後（WSL の Ubuntu 22.04 -> 24.04 で上がりました）はひょっとしたら一度も pip install をやってなかったのかもしれません。

さて、どうしたものかと思いつつ、調べてみると正攻法は venv を使う方法のようです。

• 俺流！PEP668とうまくやっていく方法 | スクエニ ITエンジニア ブログ
• PEP668エラー回避のヒント：pipxの活用 - uepon日々の備忘録
• 【私用】ubuntu24.04でpipしてもライブラリインストールできずPEP668になる件 #Python - Qiita

でも、今回は一つのプロジェクトではなく全体的に使いたいので pipx を使う方法にします。

mor@DESKTOP-DE7IL4F:~$ sudo apt install pipx
mor@DESKTOP-DE7IL4F:~$ pipx install fortls
  installed package fortls 3.2.2, installed using Python 3.12.3
  These apps are now globally available
    - fortls
done! ✨ 🌟 ✨
mor@DESKTOP-DE7IL4F:~$

同様に findent と fprettify もインストールしておきます。どっちか一方でもいいはずです。 findent は固定形式の扱いに強いらしいので、一応両方入れてみました。

mor@DESKTOP-DE7IL4F:~$ pipx install findent
  installed package findent 4.3.1, installed using Python 3.12.3
  These apps are now globally available
    - findent
done! ✨ 🌟 ✨
mor@DESKTOP-DE7IL4F:~$ pipx install fprettify
  installed package fprettify 0.3.7, installed using Python 3.12.3
  These apps are now globally available
    - fprettify
done! ✨ 🌟 ✨
mor@DESKTOP-DE7IL4F:~$

VSCode 側では特に設定は変更しませんでした（fortls, findent, fprettify にパスが通っていればデフォルトでいいみたいです）。手元の環境では ~/.local/bin に実行ファイルへのシンボリックリンクが作られていて、ここにパスが通っていました。

なお、フォーマッタはデフォルトでは findent が使われるみたいなので、 必要に応じて fprettify と切り替えて使おうと思います。

実行とデバッグ

Modern Fortran は Microsoft C/C++ 拡張機能 を使っているようです、これはインストール済みなので、飛ばします。

ついでに、 WSL 側に gdb がインストールされていることも確認しておきます。

mor@DESKTOP-DE7IL4F:~$ which gdb
/usr/bin/gdb
mor@DESKTOP-DE7IL4F:~$

さて、これで実行できるかな？と思い、さきほどのファイルを選択して『デバッグなしで実行』としても、

のように『デバッガの選択』が表示されるだけで何も起きません。こちらの記事などによると Fortran ではこのあたりをちゃんと設定してあげないとコンパイルもしてくれないようです。

というわけで設定ファイルを作成する必要があるようですね。

デバッグ設定ファイル launch.json

VSCode でプロジェクトフォルダを開いて .vscode / launch.json を作成するか、 VSCode の『実行とデバッグ』サイドメニューから『 launch.json の作成』をクリックして C/C++ を選択して、ファイルを作ってもらいます。 launch.json の内容は Modern Fortran の説明にあるサンプル（下記の Formatting の少し上に畳まれています）

をそのまま流用しました（一部日本語にしました）。

{
    // IntelliSense を使用して利用可能な属性を学べます。
    // 既存の属性の説明をホバーして表示します。
    // 詳細情報は次を確認してください: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
    {
        "name": "(gdb) Fortran",
        "type": "cppdbg",
        "request": "launch",
        "program": "${workspaceFolder}/a.out",
        "args": [], // Possible input args for a.out
        "stopAtEntry": false,
        "cwd": "${workspaceFolder}",
        "environment": [],
        "externalConsole": false,
        "MIMode": "gdb",
        "setupCommands": [
            {
                "description": "gdb の再フォーマットを有効にする",
                "text": "-enable-pretty-printing",
                "ignoreFailures": true
            }
        ]
    }
    ]
}

ビルド設定ファイル tasks.json

さて、最初に参考にしたと書いた記事は Fortran プログラムのビルドはコマンドラインからやってました。ビルドをコマンドラインから呼び出すのはちょっとなー、と思うので、これを VSCode で実行するため、

• VSCodeでFortranのプログラムをコンパイル・デバッグするための設定 #WSL - Qiita
• Ubuntu + VSCodeでFortran開発環境を構築する（WSL2対応）

などを参考にして、ビルドを行うための設定を tasks.json に書いておきます。

メニューの『ターミナル』から

『タスクの構成』を選択し、

『テンプレートから tasks.json を生成』を選び

『Others 』を選択すると、 tasks.json のひな形が作られます。これを元に、

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "FORTRAN77 のビルド",
            "type": "shell",
            "command": "gfortran",
            "args": [
                "-g",
                "-O0",
                "${workspaceFolder}/*.f",
                "-o",
                "${workspaceFolder}/a.out"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "presentation": {
                "echo": true,
                "reveal": "always",
                "focus": false,
                "panel": "shared",
                "showReuseMessage": true,
                "clear": false
            }
        },
        {
            "label": "Fortran のビルド",
            "type": "shell",
            "command": "gfortran",
            "args": [
                "-g",
                "${workspaceFolder}/*.f90",
                "-o",
                "${workspaceFolder}/a.out"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "presentation": {
                "echo": true,
                "reveal": "always",
                "focus": false,
                "panel": "shared",
                "showReuseMessage": true,
                "clear": false
            }
        }
    ]
}

という感じにしました。設定内容は必要に応じて、順次見直していくことになると思います。

テスト

さて、これでビルドとデバッグができるはずです。

まずは、 FORTRAN77 のファイルを開いて『ターミナル』から『ビルドタスクの実行』を選択します。

のように表示されるので、ここは『FORTRAN77 のビルド』を選ぶと、画面下部に

と表示されました。実際、 a.out ファイルも作成されているので、ビルド出来ているようです。

次に、先ほどのファイルにブレークポイントを設定して、デバッグ実行をしてみます。すると、

こんな感じに、ブレークポイントで止まったことがわかります。

次に同じことを .f90 のファイルを対象にしてやっても、特に問題も起きず同じ結果になりました。

とりあえずこれで最小限の設定はできたようです。

まとめ

まさか VSCode で Fortran を触る日が来るとは夢にも思いませんでした。でも、これはこれで楽しい仕事になりそうな予感がしています。