コマンドラインで Mac OS と Safari を更新
Mac では，OS を更新したいときに App Store を使うと最新版にしてくれる。現在の OS の範囲内でマイナーバージョンアップをしたいときは，コマンドラインを使うとよいらしい。
% softwareupdate --list Software Update Tool Finding available software Software Update found the following new or updated software: * Label: Safari18.5VenturaAuto-18.5 Title: Safari, Version: 18.5, Size: 184688KiB, Recommended: YES, * Label: macOS Ventura 13.7.6-22H625 Title: macOS Ventura 13.7.6, Version: 13.7.6, Size: 724837KiB, Recommended: YES, Action: restart, * Label: macOS Sequoia 15.5-24F74 Title: macOS Sequoia 15.5, Version: 15.5, Size: 6829790KiB, Recommended: YES, Action: restart,
Safariの更新と，OS の更新の候補が表示された。
現在の Safari のバージョンは何かと調べると，GUI では Version 18.3 (18620.2.4.111.8, 18620) と表示された。コマンドラインからは以下のように取得できる (Macでインストール済みアプリを一覧表示する方法｜Launchpad・Finder・ターミナルを徹底解説 | ちょげぶろぐ)。
% defaults read /Applications/Safari.app/Contents/Info CFBundleShortVersionString 18.3 % defaults read /Applications/Safari.app/Contents/Info CFBundleVersion 18620.2.4.111.8
Safari を以下のように更新する。
% softwareupdate -i Safari18.5VenturaAuto-18.5 Software Update Tool Finding available software Attempting to quit apps: ( "com.apple.Safari.SafariQuickLookPreview", "com.apple.Safari" ) Waiting for user to quit any relevant apps Successfully quit all apps Downloading Safari Downloaded Safari Installing Safari Done with Safari Done.
途中，"Waiting for user to quit any relevant apps" が表示されたタイミングで，Safari を閉じていいかというダイアログが表示された。
更新後にバージョンを確認する。
% defaults read /Applications/Safari.app/Contents/Info CFBundleShortVersionString 18.5 % defaults read /Applications/Safari.app/Contents/Info CFBundleVersion 18621.2.5.18.1
OS のバージョンは sw_vers コマンドで取得できる (Mac OSバージョンを確認するコマンド #CLI - Qiita)。
% sw_vers ProductName: macOS ProductVersion: 13.7.1 BuildVersion: 22H221
OS のパッケージは半角スペースを含むので，ダブルクォートで囲む必要がある。
% softwareupdate -i "macOS Ventura 13.7.6-22H625" Software Update Tool Finding available software Downloading macOS Ventura 13.7.6 Downloaded: macOS Ventura 13.7.6
ここから先に進まなくなる。どうにもならないので再起動してみたところ，何度か自動で再起動が行われ最終的に起動が完了すると OS が更新されていた。
% sw_vers ProductName: macOS ProductVersion: 13.7.6 BuildVersion: 22H625
LINE Messaging APIでLINEグループにメッセージを送る
LINE Notify が2025年3月末で終了してしまった。IFTTT経由で，家族のスマホパケット使用量を1日1回家族のLINEグループに送っていたのだが，これができなくなってしまった。メールで送ることに切り替えたのだが，一覧性がないので使い勝手が悪い。そこで，LINE Messaging API を使って LINE グループにメッセージを送ることにした。LINE Messaging API は有料のサービスだが，メッセージの数を抑えれば無料枠内で利用できる。1か月200通まで無料とのこと。家族は4名なので1か月を30日として120通なので無料になる計算である。
LINE Messaging API は使えるようになるまでの手順が多く面倒なのが難点。しかしながら，導入の手順を丁寧に解説してくれているサイトが複数あるので，なんとかできる。LINE 公式アカウントを作って，Developer 登録もしてメッセージを送るのだが，構造がさっぱり分からない。LINE 公式アカウント，LINE Developers，プロバイダ，チャネルの関係については，LINE Notifyが終了するのでゴミ出しbotをLINE Messaging APIに乗り換えた話 #GAS - Qiita が分かりやすく説明してくれている。おそらく，LINE 公式アカウントはアカウントの運営団体がやっていて，実際の仕組みづくりは開発業者に任せるため，プロバイダとチャネルは公式アカウントから分離させてあるのだろう。
家族の LINE グループに公式アカウントを参加させて，公式アカウントからメッセージを送るようにするのだが，それにはそのグループのグループIDを特定しなければならない。グループIDの取得方法は次の通り。あらかじめ Google Apps でプログラムを用意しておき，公式アカウントを参加させた後，家族からメッセージを送ると Google スプレッドシートに LINE グループ ID が書き込まれるようにするのだ (LINE Notifyの代替方法として、LINE Messaging APIを利用して、LINEグループに送る。 #LINEmessagingAPI - Qiita
)。実に変態的である。
処理の流れは以下の通りである。
- 自サーバで携帯電話会社のマイページをスクレイピングして，現在のパケット転送量を抽出
- 取得したパケット転送量を LINE 公式アカウントのチャネルに送る
- 公式アカウントが家族の LINE グループに投稿してくる
細かい手順については整理してから追記する。
Synology NAS にホームディレクトリがないとき
Synology NAS (DSM 7.0.1) に ssh 接続すると，ホームディレクトリがないと言われる。
% ssh adm@diskstation adm@diskstation's password: Synology strongly advises you not to run commands as the root user, who has the highest privileges on the system. Doing so may cause major damages to the system. Please note that if you choose to proceed, all consequences are at your own risk. Could not chdir to home directory /var/services/homes/adm: No such file or directory
ユーザ名は adm である。adm は root 権限を持っているので，コマンド実行の結果は自己責任でという警告が出るが，一旦無視。
最後にホームディレクトリ /var/services/homes/adm が存在しないというメッセージが出ているが，そもそもその上位ディレクトリである /var/services/homes が存在しないのである。/var/services ディレクトリを見てみると，homes がシンボリックリンクになっていてリンク先が @fake_home_link という名前からして存在が怪しいものになっている。
root@diskstation:/var/services# ls -la total 8 drwxr-xr-x 2 root root 4096 Aug 6 2023 . drwxr-xr-x 15 root root 4096 Aug 6 2023 .. lrwxrwxrwx 1 root root 24 Mar 20 2022 homes -> /volume1/@fake_home_link
これは，ユーザーホームサービスが有効になっていないのが原因である。Web インターフェイスから有効化できる (ユーザーホームサービスを有効にする方法？ - Synology ナレッジセンター)。有効化後にリンクを再度確認したところ，以下のようになっていた。@fake_home_link という実体のない先から homes ディレクトリに変わっていた。
root@diskstation:/var/services# ls -la total 8 drwxr-xr-x 2 root root 4096 Aug 12 21:17 . drwxr-xr-x 15 root root 4096 Aug 6 2023 .. lrwxrwxrwx+ 1 root root 14 Aug 12 21:17 homes -> /volume1/homes
そして，homes ディレクトリの中身は以下のようになっていた。admin はデフォルトの root ユーザである。
root@diskstation2:/var/services# ls -lad homes/* drwx--x--x+ 1 adm users 0 Aug 12 21:17 homes/adm drwx--x--x+ 1 admin users 0 Aug 12 21:17 homes/admin drwxrwxrwx+ 1 root root 8 Aug 12 21:17 homes/@eaDir
MacOS El CapitanのSourcetreeでBitbucketにプッシュ
前回に引き続き，Sourcetree 2.7.6を使っている ()。今回のリモートサーバは Bitbucket | Git solution for teams using Jira である。
Sourcetree で久しぶりにプッシュしようとすると，次のメッセージが表示された。
remote: Invalid credentials
アカウント設定は次の通り。
以前はプッシュできていたし，パスワードも合っている。実際，このパスワードでWebブラウザからログインできるし，Sourcetreeで違うパスワードを入力すると，We couldn't connect to Bitbucket with your credentials. Check your username and try the password again. というダイアログボックスが表示されるからだ。
調べてみると，Sourcetree という「アプリ」を使う場合はアプリ用の認証パスワードが必要らしい (App passwords | Bitbucket Cloud | Atlassian Support)。App passwordをBitbucketのWebサーバ上で作り (Create an App password | Bitbucket Cloud | Atlassian Support)，これをアプリのアカウントパスワードに貼り付ければよい。このパスワードは自動生成で，一度しか表示されないので，複数のクライアントでアクセスする場合は注意が必要。方法としては，同じパスワードを共有するか，クライアント毎に別のものを作るかである。クライアント別にした方が安全性は高い。パスワードはサーバに名前をつけて保存できるので，作成するときにクライアントの名前をつけておくといいだろう。
MacOS El CapitanのSourcetreeでGitHubにプッシュ
GitHub Desktop 2.2.2がまともに動かないので，Sourcetree 2.7.6を使うことにした。しかし，ここでまた問題発生。GitHubにプッシュしようとすると，次のメッセージが表示された。
git -c diff.mnemonicprefix=false -c core.quotepath=false -c credential.helper=sourcetree commit -q -F /var/folders/r1/knl8dbsd14zf3qtn2tzr4ljm0000gn/T/SourceTreeTemp.9cRxc9
git -c diff.mnemonicprefix=false -c core.quotepath=false -c credential.helper=sourcetree push -v --tags --set-upstream origin refs/heads/master:refs/heads/master
Pushing to https://github.com/user/repository.git
remote: Support for password authentication was removed on August 13, 2021.
remote: Please see https://docs.github.com/en/get-started/getting-started-with-git/about-remote-repositories#cloning-with-https-urls for information on currently recommended modes of authentication.
fatal: Authentication failed for 'https://github.com/user/repository.git/'
パスワード認証のサポートは2021年8月13日に終了しているとのこと。GitHub Desktopはパスワード認証で使っていた気がするのだが，よく分からない。理由は不明だが，確実なのは使えないことである。
他にも困っている人はいるようで，解決方法を見つけた ([Solved] remote: Support for password authentication was removed on August 13, 2021. Please use a personal access token instead. | NamespaceIT)。
- GitHub.comのウェブサイトにログインしてPersonal access tokenを発行する。Personal access tokenの有効期限は最長3か月なので，3か月したらまた同じ作業をしなければならない。
- Sourcetreeのアカウント設定画面で以下のように設定して保存する。
- (これは必須かは分からないが) Macで「キーチェーンアクセス」を起動し，github.comの「インターネットパスワード」の項目を探し，「パスワードを表示」欄からパスワードを編集してPersonal access tokenを貼り付ける。
これでプッシュができるようになった。しばらくは使えそうである。
El CapitanでGitHub Desktopが中途半端に動かなくなる
MacOS El CapitanでGitHub Desktopが中途半端に動かなくなってしまった。GitHub Desktop 2.2.2である。
先日，GitHub Desktopが勝手に更新されて起動しなくなってしまったので，古いバージョンに戻したところだった。動作しないバージョンに更新されてしまうというのも問題だし，更新後のバージョンは何になったのかと調べようとしたが，そもそも起動しないので不明なままだった。動作しないバージョンはどうでもいいとして，問題はGitHub Desktop 2.2.2である。起動すると，ログインを促すメッセージが表示されたので，ユーザ名とパスワードを入力したところ，残念なメッセージが表示された。
GitHub Desktop version is too old
起動はするが，ログインできないのでGitHub.comへのプッシュはできない。これが「中途半端」の理由である。ファイルの更新状況などは表示できるので，サーバとの同期を除けば使えはする。Gitのコマンドをまともに覚えていないので困っている。これを機にコマンドを覚えるか，別のツールを使うか悩みどころである。
GYAO!の動画をFFmpegでダウンロードする
動画サイトGYAO!がサービス終了する。
誠に勝手ながら、「GYAO!」「GYAO!ストア」「トレンドニュース」は、2023年3月31日（金）午後5時をもちまして､すべてのサービスを終了いたします。
GYAO! サービス終了のお知らせ
終わってしまう前に，気に入った動画を保存しておきたい。FFmpegで保存することができる。全自動でないのである程度は面倒であるが，お気に入りの動画を無劣化でダウンロードできるので利点はある。押さえておくポイントは次の3つ。
- ダウンロードできる動画とできない動画がある
- 動画の情報は拡張子が「.m3u8」のファイルに書かれている
- 映像と音声の2つのストリームがある
これを踏まえたダウンロードの方針は次の通り。
- ダウンロードしたい動画のページの中から「.m3u8」を探す
- 映像情報は「rendition.m3u8」，音声情報「rendition.m3u8」で同じなので，別名でダウンロード保存する
- ダウンロードした映像の形式はTS，音声の形式はAACなので，これを合体させてMP4形式にする
「.m3u8」が検索で出てこない動画はダウンロードできないので諦める。以下のシェルスクリプトを使うと上の手順が簡単になる。スクリプトにはgyao.shなどの好みの名前をつけて保存する。これはMacの例だが，Windowsのバッチファイルでも同様のことができると思われる。
おまけの動作として，タイトルに半角の「!」，「?」，全角のスペースが入っているときはsedで全角の「！」，「？」，半角のスペースに変換している。映像は仮に「tmp-$$.ts」，音声は「tmp-$$.aac」保存する。「$$」はシェルスクリプトのプロセス番号なので他のファイルとの重複を避けている。合体させてMP4ファイルを作った後に削除している。
#!/bin/bash echo "動画URL:" read movie echo "音声URL:" read sound echo "タイトル:" read title file=$(echo $title | sed 'y/!? /！？ /') ffmpeg -y -c copy "tmp-$$.ts" -i "$movie" ffmpeg -y -c copy "tmp-$$.aac" -i "$sound" ffmpeg -i "tmp-$$.ts" -i "tmp-$$.aac" -c:v copy -c:a copy -map 0:v:0 -map 1:a:0 "$file.mp4" rm -f tmp-$$.ts tmp-$$.aac
具体的な操作は以下の通り。
- GYAO!で保存したい動画のページをGoogle Chromeで開く
- Chromeのメニューから「その他のツール」→「デベロッパーツール」を開く
- デベロッパーツールの一番上で「Network」を選択
- 検索窓に「m3u8」と入力
- Chromeでそのページを再読み込みする（m3u8にマッチする行が表示される）
- Macのターミナルでgyao.shを起動
- 待っていれば完了
Chromeとターミナルを行ったり来たりする必要があるので面倒だが，ストリーミングを無劣化で保存できるのは利点だろう。
ダウンロードの様子はターミナルに表示される。回線が細いなど，状況によってはエラーが表示されることがある。その場合は，一旦Ctrl-Cでスクリプトを停止し，最初からやり直す必要がある。
エラー処理などは一切行っていないので，ダウンロード後に確認してほしい。例えば，「rendition」を選択するのに間違えるなどして，映像がないとか音声が入っていない動画になっている可能性がある。また，GYAO!のページをロードしたタイミングで回線が細いと判断された場合，低画質の情報になる場合がある。「映像のダウンロードが妙に早いな」と思ったらダウンロードを一旦止めて，ページをリロードして高画質の情報を取得し，再度ダウンロードし直すとよい。
