ちよぶろ。: Cygwin

ラベル Cygwin の投稿を表示しています。すべての投稿を表示

最終的にMSYS2へ。

Windows上でのUNIX系ツールですが、なんだか常に紆余曲折というかフラフラしているので、自分なりの考え方をまとめておこうと思います。ということで自分用メモ。1年後に「あれ？どうしてこっちを選んだんだっけ？」とかならないように。

やりたいことと前提条件。

Windows の CMD.EXE 上で 'ls' や 'grep' したい。
Neovim/Vim をコンソールでも使いたい。
Windows 上で zsh を使いたい。
できればタイリング型コンソールで作業したい。でもって zsh か Nyagos なんかがその上で動けば素敵。
Neovim/Vim では Denite.nvim なんかも使いたいので Python3 は必須。
Neovim/Vim のプラグイン管理で Dein.vim を使っているので、Git が使えないとまずい。
LaTeX は TeXLive のものを使う。
Python3 は公式のものを使う。
Perl はなんでもいいけど、Neovim/Vim の Dein.vim で使う Git がちゃんと使えること。

Git リポジトリを Python から使う Dulwich （ダルウィッチまたはダリジ）というプロジェクトもあるようで、もしかしたらこれでもいいかもしれません。が、Dein.vim は Git を要求しているようです。

4の項目があるので、「タイリング型ターミナルエミュレータでSHELLを指定できるもの」かつ「256色表示可能であること」の条件で、RLogin を使うことは既定です。そして、OpenSSH for Windows を使えば SHELL を変更することができて、RLogin から Nyagos を呼び出して使うことができることは確認済みです。なので、これまで SSH サービスを動かしていた Cygrunserv は不要になります。

これまで Cygwin64 を使っていましたが、そういうわけで積極的に Cygwin64 を選択する必要はなくなりました。
すると、MSYS2 と Cygwin64 と Git for Windows が横並びになるわけですが、

Cygwin64
- cygwin-1.dll を必ず呼び出す必要がある。
- C:ドライブを指定する場合に /cygdrive/c などの形式になる。
- cygdrive の部分は /etc/fstab で変更できる。
- Dein.vim での動作で Git でのパスの扱いがうまくいかなかった記憶がある。
- パッケージマネージャは setup
MSYS2
- Windows ネイティブバイナリと msys-2.0.dll を呼び出すバイナリがある。
- C:ドライブを指定する場合に /c という形で参照できる。
- パッケージマネージャは pacman
Git for Windows
- MSYS2 と同じだが、同梱の msys-2.0.dll を呼び出すため、MSYS2 とは共存しないほうがよい。

というような感じでしょうか。

なので MSYS2 に切り替えてしばらく様子見です。

Windows 10 1809とOpenSSH。

Cygwin を使って、Windows 上での sshd の動作を見ていたんですが、コンソールから whereis したら、

$ whereis sshd
sshd: /usr/sbin/sshd.exe /mnt/c/WINDOWS/System32/OpenSSH/sshd.exe /mnt/c/Program Files/Git/usr/bin/sshd.exe /usr/share/man/man8/sshd.8.gz

などと出てきてびっくり。
Git はともかく、自分では Cygwin 以外に OpenSSH をインストールした覚えはないのに、なぜか \Windows\System32\OpenSSH なんていう場所にあります。なにそれという感じです。

調べてみると、Installation of OpenSSH For Windows Server 2019 and Windows 10というページが見つかりました。
Windows 10 1809 と Windows Server 2019 ではインストール可能な機能として構成されるようになった、みたいなことが書いてあります。

SSHクライアントの方は 1809 でインストールされているようですが、SSHサーバのほうは明示的にインストールが必要なようです。

「アプリと機能」の中にある「オプション機能の管理」に進みます。

「機能の追加」をクリックします。

すると「OpenSSHサーバー」が出てきます。

インストールすると、上記のディレクトリにサーバが追加されました。

"sshd.exe" "sftp-service.exe" "sshd_config_default" という3つのファイルのようです。

…これ、もしかしてcygwinいらなくなるんじゃね？という思いがふつふつと。
RLogin とか ConEmu を使って自分の PC に SSH ログインしてシェルをタイリング（タブではなくて画面分割）できるコンソールで作業できるのでは。そもそも Cygwin の sshd を使ってログインしてもシェルとして Nyagos とかは使えなかったので、これは試してみる価値があるかもしれません。

ということで sshd_config_default を見てみます。

#HostKey __PROGRAMDATA__/ssh/ssh_host_rsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_dsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_ecdsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_ed25519_key

どうやら c:\ProgramData\ssh 以下に鍵ファイルや設定ファイルがあるようです。そこを開いてみると、

いつインストールされたのかわかりませんが、すでに鍵ファイルなどがありました。しかも sshd_config ファイルまであります。
鍵の暗号方式にはいくつかの種類がありますが、RSA が使えるようになったので DSA はもはや不要、RSAでも2048bit以下はダメで、使うなら4096bit以上、それよりは ECDSA か、さらに強度の高い Ed25519 が推奨、ということになっています。
外部に晒す環境であれば、最低でも "PasswordAuthentication" は "no" にしなくてはいけませんが、まずは実験なのでデフォルトのままにしておきます。使えると分かれば "no" にします。

まずは Windows の「サービス」から Cygwin の sshd を起動しないようにします。うちの場合には Cygwin xinetd を停止して無効にしておきます。

次に、Initial Configuration of SSH Serverにあるように、PowerShell を管理者モードで起動して sshd をサービスとして登録します。

Start-Service sshd
# OPTIONAL but recommended:
Set-Service -Name sshd -StartupType 'Automatic'
# Confirm the Firewall rule is configured. It should be created automatically by setup. 
Get-NetFirewallRule -Name *ssh*
# There should be a firewall rule named "OpenSSH-Server-In-TCP", which should be enabled

コマンドプロンプトアイコンを右クリックすると「管理者として実行」というメニューが出るので、管理者モードのコマンドプロンプトを開いて PowerShell を起動していますが、ちゃんと登録できたようです。「サービス」を開いて確認すると登録されています。

どうやらインストールは終わったようなので、次は接続編です。

Cygwin 3.x。

3月5日に Cygwin 3.0.2 がリリースされたようです。

Cygwin version
The most recent version of the Cygwin DLL is 3.0.1.

Note that Cygwin version 2.5.2 was the last version supporting Windows XP and Server 2003. (Instructions for obtaining that version)

3.0.0のリリースは見逃していたんですが、WinXPをサポートしているのは 2.5.2 までで、2.5.2 の Cygwin をインストールするならこっちを見てね、だそうです。

What changed:
-------------

- Windows 10 1803 or later and WSL installed:

Starting with 3.0.0, mkdir(2) automatically created directories within
the Cygwin installation dir as case sensitive. This badly breaks
interoperability with remote machines trying to access these dirs.
Therefore, disable this as default. You can still create case-sensitive
dirs via `chattr +C ...'

3.0.2 では Windows 10 1803 以降でかつ WSL がインストールされている場合に、mkdir(2) でケースセンシティブなディレクトリ作成を行っていたのを、デフォルトではしないようにしたようです。3.0.0-1 のリリースノートはこれですかね。

WindowsでHere-docを使ってみる。

Here-docもしくはヒアドキュメントというのは、文字列をシェルスクリプトやプログラムコード中に埋め込む方法の一つです。

UNIX系のシェルである sh （Linux系ではbashへのシンボリックリンクであることが多い）では、たとえば

$ cat << _EOT_
> hello, world.
> _EOT_
hello, world.
$

などというように、 _EOT_ で囲まれたものをコマンドへの標準入力に食わせるために使います。_EOT_ は前後で同じものを使えばいいので、食わせたいテキスト中に同じものがなければなんでも可能です。ちなみに EOT は "End of Text" の意味で、慣用句としてよく使われます。
同じことはPythonでもできます。

$ python - << _EOT_
print('hello, world')
_EOT_
hello, world
$

この場合には _EOT_ で囲まれた部分をスクリプトとして Python に食わせています。
この手法を使えば、ひとつのシェルスクリプトの中にPythonのスクリプトを埋め込むことで、スクリプトファイルを一つにまとめることができます。

とここまでを踏まえて。

これをWindowsで使えないかと思ったのがここでの趣旨。バッチファイル内にpythonスクリプトを埋め込めば、いくつもファイル作らなくて済むじゃん、というお話です。可読性は落ちますが…。

まず cmd.exe では、調べてみたけれどHere-docは使えないようです。()を使うというトリッキーな方法がありますが、これはちょっと筋が違うので却下です。stackOverflowにも heredoc for Windows batch? というような記事がありますが、ちょっと一筋縄ではいかないようです。他にも How to use “<<” in batch file or command prompt? というトピックがsuperuser.comにあります。

次に Windows PowerShell では、@' と '@ （および @" と "@）で囲んだ部分を here strings（ヒア文字列）という形で利用できるようです。ちょっとPythonに食わせられるかどうかを試してみます。

PS C:\Users\kats> python - @'
>> print('hello, world')
>> '@
Python 3.7.2 (tags/v3.7.2:9a3ffc0492, Dec 23 2018, 23:09:28) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> ^Z

PS C:\Users\kats> @'
>> print('hello, world')
>> '@ | python -
hello, world
PS C:\Users\kats>

見て分かる通り、Pythonにうまく食わせるには、冒頭に 'python -' ではなくて、パイプで '|python -' してやればいいようです。ちなみにダブルクォーテーションを使うと変数の展開が行われるようです。

さらに Nyagos を見てみると、Support Here Document #130を参照する限り、残念ながらHere-docはまだ組み込まれていないようです。

なので、Windows環境でHere-docを使うには、WSLやCygwinを除けば今のところ Windows PowerShell に頼るしかないようです。

…でもWPSはよくわからない…（というかわかろうとしていない）。

Cygwin64 互換性のないランタイム。

KiCADのライブラリのうち、3Dモデルが1GBを超えていたので中身を見てみたら*.stepファイルが巨大だということがわかりました。

なので一括削除しようとして

find -name *.step | xargs rm

しようとしたら、エラーだよ、ランタイムの互換性がないんじゃないの、と言われました。

思い当たるのは、Git for WindowsとCygwin64をインストールしていて、パスはGfWのほうが先に参照されるようになっていること。なので、Cygwin64のfindからGfWのrmを呼び出そうとしてコケていたようです。

ご存知の通り、CygwinはWindowsのドライブを /cygdrive/c/ のような形で仮想的にマウントして扱います。一方、MSYS2（GfW含む）は /c/ という形で参照します。これまでは後者のほうが都合がよいのでGitはGfWを使用し、その他の場合にはCygwin64を使っていたのですが、上記のエラーが出てきたのでGfWはやめることにしました。

ちなみにマウントポイントの指定ですが、Cygwin64の場合には、c:\Cygwin64\etc\fstabを編集することで変更することができます。
うちの環境では

none /mnt cygdrive binary,posix=0,user 0 0
c:/cygwin64/bin /usr/bin ntfs binary,auto 0 0
c:/cygwin64/lib /usr/lib ntfs binary,auto 0 0

として、cygdriveを/mntに変更しています。

Cygwinのsetup.exeまで含めたアップデート方法。

Cygwinが、たとえばpacmanやrpmのようなパッケージマネージャを使わずにsetup.exeを使わせるのは、Windowsの仕組みとして「開いているファイルは上書きができない」というのが根底にあって、そのためにpacman自身やそれを実行しているshellなどのアップデートがうまくいかないから、らしいです。

なのでsetup.exeを使うわけですが、setup.exeを実行すると「新しいバージョンがあるのでそっちを使って」とかメッセージが出てきて、けっこう煩わしい。setup.exe自身も同様の理由で自分をアップデートできない、ということなんですが…。

じゃあpipはどうなのよ、という話もありますが、Windows環境でpipをアップデートするときには "python -m pip install pip --upgrade" という形で実行するので、pythonがpipを読み込んだあとでcloseしてしまえばできるんだよ、ということですね。きっと。

で、setup.exeのほうは煩わしいので以下のようなバッチファイルを書いてみました。

cygupdate.bat:

wget -N https://cygwin.com/setup-x86_64.exe.sig
wget -N https://cygwin.com/setup-x86_64.exe

gpg2 --verify setup-x86_64.exe.sig setup-x86_64.exe

pause

if not %ERRORLEVEL% == 0 (
  echo BAD Signature!!
  pause
) else (
  setup-x86_64.exe
)

こうしておくと、setup.exeが更新されていた場合にはwgetがリトリーブしてきて、署名も確認してくれて、よければそのまま実行されます。
わりと楽ちん。

登録: 投稿 (Atom)

ちよぶろ。