screenコマンドは私のお気に入りのコマンドです。 screenを使うと、複数の仮想端末を起動して、好きなタイミングで切り替えられます。 また、ターミナルソフトからホストへの接続を切り離して(=ログアウトして)、 後ほど再ログインしても仮想端末はそのまま終了せずに残っています。

このように非常に便利なツールなので、もし使えないと作業効率が大幅に低下してしまいます。

さて、WSL(Windows Subsystem for Linux)で動作するUbuntu 18.04LTSでscreenコマンドを起動すると、次のメッセージを表示して失敗します。

Cannot make directory '/run/screen': Permission denied

screenが使えないと困るので、調査してみました。

screenがソケットを作るディレクトリ/run/screenが無いのが原因でした。 このディレクトリを作ってやれば解決するのですが、 調べてみると、WSLでは、手で/run/screenを作っても、ブート時に消されてしまうようです。

そこで、環境変数SCREENDIRによって、ソケット用のディレクトリを指定することにしました。 具体的には、~/.bashrcに次の1行を追加してやれば、(次にログインした時から)screenコマンドが使えるようになります。

export SCREENDIR=$HOME/.screen

Windows 10では、WSL(Windows Subsystem for Linux)を利用して、Linuxを動かすことができます。 私は、ノートPC(Windows 10)に、Ubuntu 18.04LTSをインストールしていますが、やはり手元のマシンでLinuxが使えるのはとても便利です。

しかし、Emacsでシンタックスハイライトをすると、配色が暗すぎてとても見づらく、 またターミナルのフォントも読みにくいので困っていました。

調べてみると、WSL用のターミナルソフトがいろいろと出回っていることがわかりました。 そこで、Wslttyというターミナルソフトをインストールしました。 その際のメモ書きです。

Wslttyのリリースページ(https://github.com/mintty/wsltty/releases)から、最新バージョン(一番上にあるもの)のインストーラーをダウンロードします。 2019/6/8時点では、バージョン3.0.1.2が最新でした。

インストーラーの名前は「wsltty-バーション番号-install.exe」となっており、 この名前のリンクをクリックするとダウンロードされます。 インストーラーを実行して、wslttyをインストールしました。

wslttyを起動して、右クリックで「options…」を選択すると、いろいろとカスタマイズができます。 私は、カーソルをブロックカーソルにして、ターミナルを256色モード「xterm-256color」に設定したくらいです。

詳しい使い方や設定は、以下のリンクを参照してください。

• WSLのコンソールを便利で高機能な「wsltty」に置き換える：Tech TIPS - ＠IT
• WSLを使うなら必須！「wsltty」で快適シェル環境を整える！

さて、wslttyを使ってみて1つだけ気になる点がありました。 デフォルトのままだと、日本語のフォントがしょぼいのです。こんな感じです。

アルファベットのフォントは見やすいのに、日本語がこれでは情けないですね。

調べてみると、日本語対応のプログラミング用フォントRicty Diminishedというのが良さそうだったので、インストールしました。

• プログラミング用フォント Ricty Diminished

ダウンロードして展開すると、ttfファイル(True Type Font)が入っているので、 「Widowsフォント ビューワー」で開いて、「インストール」ボタンをクリックすると、インストールされます。 次の4種類のフォントをインストールしました。

• RictyDiminished-Bold.ttf
• RictyDiminished-BoldOblique.ttf
• RictyDiminished-Oblique.ttf
• RictyDiminished-Regular.ttf

そして、このように日本語が美しく表示されるようになりました。めでたしめでたし。

2月からブログがアクセスできない状態になっておりました。

先週、ブログをGitHub Pagesから、AWS S3のウェブホスティングに移行して、再びアクセスできるようになりました。 本来なら、ついでにTLS化(SSL化)するべきなのですが、最低限の手間で済むように、今回はHTTPのままで移行しました。

さてアクセス不能になった原因についてです。

従来はGitHub Pagesで独自ドメインでブログを公開していました。 先日、GitHubの契約を、有料プラン(月7ドル)から無料に変更したのですが、それが原因のようです。 調べてみると、無料プランでは、privateリポジトリのGitHub Pagesがサポートされなくなっていました。

ブログ自体はJekyllを記述して、それをGitHub Pagesで公開していました。 でも考えてみれば、Jekyllは静的サイトジェネレータですから、Jekyllが生成したサイトのファイル一式をS3にアップロードすれば、そのままウェブでアクセスできるはずです。

調べてみると、やり方はとても簡単でJekyllでサイトを生成した後に、_siteの中身をまるごとS3バケットにミラーリングするだけでした。こんな感じです。

$ jekyll build
$ cd _site
$ aws s3 sync . s3://blog.kondoyoshiyuki.com/ --delete

S3への移行自体はとても簡単でしたが、S3のバケットを公開するための手順で手間どってしまいました。 「S3バケットを誰でもアクセスできるようにする」ためには、コンソールでデフォルトの設定を数か所変更する必要がありました。

これは、「S3バケットを意図せずにグローバルアクセス可能にしてしまう」事故を防ぐためなんでしょうね。

たまにしか行なわないので、やり方を忘れてしまい、毎回調べることになる操作のメモです。

GitHubではブランチを削除するUIが用意されていますが、タグ(GitHubでは「リリース」)を削除できないみたいなので、ローカルから行なう方法を調べてみました。

gitで、リモートリポジトリ(要はGitHub)のタグ(TAGNAME)を削除するには、次のようにします。

$ git push --delete origin TAGNAME

以下は、よく行なうのでやり方を覚えている操作だけど、念のためにメモしておきます。

ローカルのタグ(TAGNAME)を削除する。

$ git tag -d TAGNAME

ローカルのタグをリモートリポジトリに反映する。

$ git push --tags

たまにしか行なわないので、やり方を忘れてしまい、毎回調べることになる操作のメモです。

gitで、あるコミットのファイルの内容を知るには、git showを使って次のようにする。

$ git show ハッシュ:ファイルのパス名

例えば、次のコマンドで、ハッシュ333efのpath/to/fileの内容が標準出力に表示される。

$ git show 3333ef:path/to/file

ファイルをカレントディトリからの相対パスで指定するには、パス名を./で始めればよい。

$ git show 3333ef:./myfile.c