📝

WSLでビルドしたsphinxのhtmlをブラウザ(IIS経由)で表示できるようにする

2023/08/29に公開

https://qiita.com/items/8ae8c833f8abeaf74655


お詫び

Qiitaの元記事にて、区切り線を「---」で書いている場所があり、これがZennの記法に干渉して一部うまく表示できない記事がある事を認識しています。
全ての記事を精査しきれていないため、お手数ですがお見かけの際は教えていただけると大変喜びます。


謝辞

Windows10に入れられるUbuntuの名称が変わっていたようで、Windows Subsystem for Linux(WSL)と呼ぶのが正しいようです。
途中で気付いて旧称のBash on Windows on Ubuntu(BoWoU)を使っていたため、後に一括変換で直したのでおかしな表現があるかもしれません。
最近までBoWoUと思っていたばかりに、そのように略した記事を置いてるのが結構恥ずい…

気付いた方は適宜WSLと読み替えてもらえると喜びます。

WSLでビルドしたsphinxのhtmlをブラウザ(IIS経由)で表示できるようにする

まずはじめに、掲題のようなケースならIISなんて使ってないでapacheとかnginxとかでWebサーバーを立てて使った方がいいです。
が、今回は制限の下で実施してます。

当然の疑問のQ&A

なぜ置くだけではだめなのか?

システム直下にファイルを置いて、Windows側で動いているシステムにファイルを読ませる時に、権限がないのでこれらのファイルを読みに行けないのです。
たとえば、sphinxでビルドしたhtmlファイルをブラウザから見に行きたい、という事が考えられますが、Windows側でこれらのファイルに権限がないため、存在しないものとして振舞います。
Windows側の管理者権限をもったプロセスがファイルを操作しないと、

Powershellでsphinxをビルドすればよいのでは?

全くもってその通りです。
当初はsphinx、というかドキュメントは後からゆっくりやろうと思ったツケがきました。
というのも、makeファイルとかパッケージ管理がつらくて、WSLでやった方が楽[1]だったのでPowershellを選択しませんでした。
その割にはIISは使ってるのでなんだこれは、となりますが…。

WSLからWindowsのアクセス権限エラーを回避してファイルを格納する

では、本題を。

まずはじめに、置くだけなら/mnt/c/Windows/...とかに直接置けばやりたい事はできると思います。
あるいは、WSLを管理者権限で実行してから同じようにコマンドを実行するのでも良いかと思います。

それでもダメだった方が対象です。
が、正直な話をすると開発環境を作るためだとか、大人の事情で仕方なくやる場合以外は素直にVagrantとか、Hyper-Vとかがあるのでそっちの方がいいですよ。
大事なことなので二回目です。

作業環境

(root)
├── call.sh
├── 01_wsl_startup_cmd.bat
├── 02_cmd_startup_psh.bat
└── 03_psh_execute_command.bat
# 予めsphinx関連のmakeを実行しておく

cd $(dirname ${0})
$(pwd)/01_bow_run_cmd.bat
/mnt/c/Windows/System32/cmd.exe /k C:\\(rootまでのWindows形式のフルパス)\\02_cmd_startup_psh.bat
powershell start-process "03_psh_execute_command.bat" -verb runas
exit
(Windowsコマンド) \(sphinxでビルドしたディレクトリのフルパス)\ C:\inetpub\wwwroot\sphinx

解説

まずは通常通りsphinxでドキュメントファイルを作成します。
sphinxについては色々な場所で公開されている、すばらしい記事を参照してください。

call.shはドキュメントファイルがビルド出来た後からの実施です。
call.shにはWSLからbatファイルを実行させるようにしていますが、実際はただのテキストをコマンドラインに流しているだけです。
. xxx.sh のような形で実行していると思ってください。

なお、WSLからexeを起動できますが、起動したexeを操作することはできません。
今回はcmd.exeなので、cmd自身に終了コマンドを実行させてWSLを復帰させています。[2]

あとはファイルをだれが実行しているのか、というだけです。
02.batを実行するのはcmdではなくpowershellでもいいんですが、WSLからwindowsの管理者権限で実行させることが出来なかったので、

  • 01_callfrom_WSL: windowsで実行できるcmdを呼ぶ
  • 02_callfrom_cmd: windowsの管理者権限を持たせてpshを呼ぶ
  • 03_callfrom_psh: 管理権限を持っているのでコマンドを実行する

と、役割分担させています。

ハマりどころ

powershellを使った事がないので、cmdを使わずpowershellで一本にしよう、というのが高い敷居になりました。
実装中はよく混乱させられたので、早いタイミングで上記のようにそれぞれの目標を明確化しました。
後述のメモの通り、なんとかならないかなぁ、と思ったものですが…

あと、どのタイミングをWSLが持つのか、Windowsが持つのかは意識しながらパスを書きましょう。
スラッシュとバックスラッシュ、バックスラッシュの場合は個数にも注意が必要です。

メモ

<a href="https://qiita.com/resolver/items/7187bd6ee8016ee5c741">参考先</a>でも紹介されている通り、batが複数あるのは運用上思うところがあるので、01_bow_run_cmd.batはshでもいいと思います。
が、ここではよく分からない事になりそう[3]なので拡張子をbatで統一して説明しますが、実際に運用する時はいい感じにしておかないと混乱します。

参考

<a href="https://qiita.com/resolver/items/7187bd6ee8016ee5c741">管理者権限でbatを実行したい時にやッた事</a>

読了後いいね!をお願いします。

どれだけの方に読んでもらっているか知りたいので、お手数をおかけしますがご協力いただけると嬉しいです。

脚注
  1. 【WSLでやった方が楽】pip install sphinxが優秀すぎた ↩︎

  2. 【WSLを復帰させる】02_cmd_startup_psh.batにexitを書いているためです。01_wsl_startup_cmd.batにexitとしても実行されません。 ↩︎

  3. 【よく分からない事になりそう】windowsの権限をどうにか回避するためにやってる事なので、WSLからもbatをshとして呼び出します。 ↩︎

GitHubで編集を提案

Discussion