Quantcast
Channel: My Future Sight for Past
Viewing all 265 articles
Browse latest View live

Solution for gcc "x86_64-linux-gnu/crti.o: unrecognized relocation (0x2a) in section `.init'" on Ubuntu 16.04

$
0
0

先日Ubuntuを14.04から16.04に更新した。すると,gccでC言語のソースコードをコンパイルしようとすると以下のエラーがでるようになってしまった。

cat << EOF > hi.c
#include <stdio.h>
int main(void){
puts("HI");
return 0;
}
EOF
gcc -o hi.{exe,c}
/home/senooken/local/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o: unrecognized relocation (0x2a) in section `.init'
/home/senooken/local/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status

原因を調べていると以下のページにたどり着いた。

GNAT GPL 2015 and Ubuntu 16.04 => ld: /usr/lib/x86_64-linux-gnu/crti.o: unrecognized relocation - Google グループ

この投稿でPascal Obryの回答を参考にすると,どうやらコンパイルに使ったgccとリンカldのバージョンなどの整合性が取れていないことが原因のようだ。

実際に以下のコマンドでldがどこにあるか確認した。

which ld/home/senooken/local/bin/ld

どうやら,自分でローカル環境にインストールしていたldを使っていたようだ。

確認してみると,ローカルでbinutils-2.25をインストールしていて,gccでのリンク時にこのldが使われていたのが原因だった。binutils-2.25をアンインストールしたら解決した。

gccはOSのシステムと密接になっているので,注意しよう。


Solution for "Gtk-WARNING **: cannot open display:" on Ubuntu 16.04

$
0
0

先日Ubuntu 14.04からUbuntu 16.04にアップグレードした。しかし,Gnomeのアプリを起動しようとすると起動できなかった。解決できたのでメモしておく。

結論を先に書くと,環境変数DISPLAYは自分で設定するのではなく,~/.bashrcなどで以下のとおりに設定されていないときだけ設定すればよい。

[ "${DISPLAY}" ] || export DISPLAY=:0

Trouble

例えば,テキストエディタであるgeditをターミナルから起動しようとすると以下のエラーが出た。

geditGtk-Message: Failed to load module "unity-gtk-module"
No protocol specified

** (gedit:19866): WARNING **: Could not open X display
No protocol specified

(gedit:19866): Gtk-WARNING **: cannot open display: :0.0

環境変数DISPLAYの値は:0.0としている。以下のコマンドでDISPLAY変数の値を一時的に無効化してgeditを起動するとエラー内容が若干変化した。

DISPLAY="" geditGtk-Message: Failed to load module "unity-gtk-module"

(gedit:20071): Gtk-WARNING **: cannot open display:

EvinceやGIMPなどのGTK+をベースとした優れたGnomeのアプリを端末から使えないのは不便なので,解決策を調べた。

Solution

まず,最初に両方のエラーに表示されていた以下のメッセージに注目して調べてみた。

Gtk-Message: Failed to load module "unity-gtk-module"

すると,最初に以下のサイトにたどり着いた。

Ubuntu 16.04, D1000 Docking Station, displaylink-driver-1.1.62 - DisplayLink Forum

このサイトで回答されている通りに,以下のコマンドを入力してみたのだけど,解決しなかった

sudo apt-get install --reinstall ubuntu-desktop

続いて,cannot open display:のメッセージからX Window System関係の問題かなと思って調べてみたところ,以下のサイトにたどり着いた。

command line - Can't launch graphical apps from terminal after updating to 15.10 - Ask Ubuntu

このサイトでsssemilが回答しているように,DISPLAY=:1のとおりに環境変数に値を設定して起動してみる。

DISPLAY=:1 gedit

起動に時間がかかったものの,うまく起動できた

Cause

今までよくわからないまま,~/.bashrcなどで環境変数DISPLAYには以下のとおりに:0.0を設定していた。

export DISPLAY=:0.0

これがまずかったようだ。ちょっと調べてみた。man Xコマンドかこのサイトでヘルプを確認できる。Display Namesセクションを一部翻訳しながらまとめてみる。

DISPLAY環境変数の値の書式は以下のとおりになっている。

DISPLAY=<hostname>:<displaynumber>.<screennumber>

この情報は,デフォルトでサーバーとスクリーンに接続する方法を決めるために,アプリケーションで使われる。

項目説明既定
hostnameディスプレイが物理的に接続されているマシン名を指定する。指定しなければ,サーバーと最も効率のよいマシン名が使われる。自動
displaynumberディスプレイとは,キーボードやマウスポインターを共有するモニターを指す。多くのPCでは1PCにつき1モニターを持つ。マルチユーザーシステムでは,ログインユーザーごとにディスプレイが存在し,それぞれ割り当てられる。混乱を避けるため,Xサーバーの起動時に,各ディスプレイに0から始まるディスプレイ番号が割り当てられる。ディスプレイ番号はいつもディスプレイ名で与えられないといけない。-
screennumberキーボードとマウスポインターを共有するディスプレイ。Xサーバーの起動時に,各モニターは自分のウィンドウを持ち,各スクリーンは0から始まるスクリーン番号を割り当てられる。番号を指定しなければ0が使われる。0

<hostname>と<screennumber>は既定値があるので,基本的には<displaynumber>だけ自分で設定すればよさそうだ。また,以下で言及があるようにPOSIX準拠である大半のLinuxではDISPLAY環境変数の既定値が存在する模様。

On POSIX systems, the default display name is stored in your DISPLAY environment variable. This variable is set automatically by the xterm terminal emulator. However, when you log into another machine on a network, you may need to set DISPLAY by hand to point to your display.

このことから,基本的には自分で設定する必要はないだろう。しかし,CygwinやMSYS2などでは環境変数DISPLAYの値が設定されていない環境もありえるため,エラーを回避する必要がある。そこで,DISPLAY環境変数が存在すればそのままにし,存在しなければ自分で設定すればよいだろう。設定値についても,基本的には既定値を使えばよい。

これらのことを考慮して,以下の設定を~/.bashrcなどに書いておけば今後も大丈夫だろう。

[ "${DISPLAY}" ] || export DISPLAY=:0

How to use ShellScript file arguments in user defined function

$
0
0

シェルスクリプトで,ユーザー関数でスクリプトファイルの引数を使う方法がわかったのでメモしておく。端的に結論を書くと,ユーザー関数の引数に$@を渡せばよい。

シェルスクリプトの引数はスクリプトでよく使われるパラメーターだろう。例えば,シェルスクリプトに渡す引数の既定値を設定したり,引数の数や内容を確認して,ユーザーに問い合わせるような処理に使われるだろう。

こうしたスクリプトファイルの引数を使った定型処理をユーザー関数にして,他で使いまわしたり管理しやすくしたい。

スクリプトファイルの引数は,位置パラメーターである$$1$2,…,$n$@$*などで参照できる。しかし,シェルスクリプトのユーザー関数内ではこれらの位置パラメーターはユーザー関数の引数として解釈されてしまう。そのため,引数が何個渡されるかわからないときに対応しにくい。

一応,以下のようにスクリプトファイルの引数をユーザー関数の引数に渡して実行することは可能だ。

echo << EOF > arg_parse.sh
#!/bin/bash
## \file arg_parse.sh

arg_parse(){
[ "$#" -gt 4 ] && echo "arguments $# is too much!"&& return 1
echo $1 $2 $3
return
}

arg_parse $1 $2 $3 $4
EOF
./arg_parse.sh one two three four
arguments 4 is too much!

しかし,これだと引数の個数を決め打ちで指定する必要があり,引数の個数が何個くるかわからないときの処理が難しく,見た感じもよくない。

この解決策としては,ユーザー関数の引数に$@を渡せばよい

echo << EOF > arg_parse.sh
#!/bin/bash
## \file arg_parse.sh

arg_parse(){
[ "$#" -gt 4 ] && echo "arguments $# is too much!"&& return 1
echo $1 $2 $3
return
}

arg_parse "$@" # <- here
EOF
./arg_parse.sh one two three four
arguments 4 is too much!

$@は,スクリプトファイルに渡された全ての引数が代入されている。ユーザー関数の引数にスクリプトファイルの全ての引数を渡すことで,スクリプトファイルの引数が何個であろうともユーザー関数で取り扱うことができる。

$@と類似のパラメーターとして,$*がある。こちらも全ての引数が格納されている。こちらは$@とは異なり各引数の区切り文字がIFS変数となっている。$*IFS変数と併用して引数をカンマ区切りにしたり加工するのに便利だが,通常の利用であれば$@で十分だろう。

これで,スクリプトファイルの引数が何個であろうと,ユーザー関数でもスクリプトファイルの引数を処理できるようになった。今後はシェルスクリプトでのスクリプトファイルの引数はユーザー関数で処理してやろう。

How to exclude binary file or directory in Vim internal/external grep

$
0
0

テキストエディターVimでは,起動中に内部grep(:vimgrep)と外部grep(:grep)により複数のファイルから文字列を検索できる。この検索からバイナリーファイルや特定のディレクトリを除外する方法をまとめる。

大量のファイルから特定文字列を探していると,検索に時間がかかり,不要なマッチがあると重要なマッチが埋もれてしまうので,無関係のファイルは検索対象から除外したい。特に,バイナリーファイルや,.git.svnなどのバージョン管理のためのディレクトリは,文字列を検索する文字列を検索する意味がないので検索対象から除外したい。

調べてみたが,あまりまとまった情報がなかったのでまとめてみた。設定一覧は最後のまとめの節に掲載している。

目次

  1. 内部grepと外部grep
  2. 内部grep(:vimgrep)
    1. 検索対象外ファイル・ディレクトリの設定
    2. wildignore設定時の注意点
    3. Vim script構文を使ったスマートな設定方法
    4. vimgrepで気づいたこと
  3. 外部grep(:grep)
    1. findstr(Windows)の設定
    2. GNU grepコマンドのオプション
    3. Unixでのgrepprgの既定値の/dev/null
    4. Vimの外部grep(:grep)とシェルのgrepコマンドのオプションの共通化
  4. まとめ
内部grepと外部grep

まず,Vimの内部grep(:vimgrep)と外部grep(:grep)について簡単に説明する。

内部grep(internal grep,:vimgrep)とは,Vimの内部コマンドによるgrep検索のことである。利点と欠点は以下となる。

利点
  • Vimで直接ファイルを一つずつ開いて検索をかけるため,Vimがもつ文字エンコーディングの自動判別や正規表現が使える。
  • Vim標準機能であるため,どのOSでも利用可能で,操作や結果も同じ。
  • 検索後の問い合わせがなく検索結果にシームレスにアクセスできる。
欠点
  • ファイル数が増えると検索に時間がかかる。

外部grep(external grep,:grep)とは,Vimから外部のコマンドを使用するgrep検索のことである。既定ではUnix系OSではgrepコマンドが使われ,Windowsだとfindstrコマンドが検索に使われる。利点と欠点は以下となる。

利点
  • 外部の専用検索コマンドを使うことで,ファイル数が多くても検索速度が早い。
欠点
  • 外部コマンドに依存するため,OSによりコマンドや操作・結果に若干の違いが生じる。
  • 文字エンコーディングの自動判定などの機能が内部grepよりは貧弱。
  • 検索実行後,Press Enter or type commmand to continue問い合わせメッセージが表示されるので,頻繁に検索を実行する場合煩わしい。

使ってみた印象だと,検索対象ファイル数が数十ファイルを越えるなら,確実に外部grepを使ったほうがよい。ただ,外部grepを使うと,検索後に検索結果一覧を表示してメッセージが表示される。頻繁に検索を繰り返す場合,これが煩わしく感じるかもしれないので,検索対象ファイル数が少なければ,内部grepでもよい。

Vimからgrepを使うことで,Vimを離れることなく検索したファイルにアクセスができる。QuickFix-windowと組み合わせることで,大量のファイルから該当文字列を含むファイルだけをつぎつぎとアクセスでき,とても作業効率がよくなる。

内部grep(:vimgrep)
検索対象外ファイル・ディレクトリの設定

Vimの内部grep(:vimgrep)でバイナリーファイルやディレクトリを検索対象外にするには,wildignoreで設定する(参照:5.1 Vimの内部grepの使い方 - quickfix - Vim日本語ドキュメント)。

設定はVimの正規表現の形式で設定する。例えば,ファイルを対象外にするには以下の通りに拡張子で指定したり,ファイル名で指定する。

set wildignore=*.dll,*.exe,tags

:vimgrepではファイルを自動的に判別して,バイナリーファイルを検索対象外にすることはできないようなので,考えられるバイナリーファイルの拡張子を複数指定して検索対象外にする。

ディレクトリを対象外にするには,vimやbash,zshで特有の正規表現である**を使い,ディレクトリ配下の全ファイルを無視するように指定する(参考:vim - How to exclude file patterns in vimgrep? - Stack Overflow)。

set wildignore+=obj/**,.git/**,.svn/**
wildignore設定時の注意点

wildignoreで値を設定するときは,help: wildignoreで以下のとおりにすることが推奨されている。

リストにパターンを追加するときにはコマンド |:set+=|、リストからパターンを除くときにはコマンド |:set-=| を使うのがよい。こうすると将来のバージョンで異なった既定値が使われるようになったときに、問題が起きるのを防げる。

wildignore - options - Vim日本語ドキュメント

上記の通り,設定するときは既定の設定を壊さないように,:set+=で追加し,:set-=で解除するのがよいだろう。

併せて,「内部grepでバイナリファイルを対象外にする - 座敷牢日誌」で言及されているように,wildignoreの設定は,Vimのgrep以外にも影響を与えるので,そのまま設定するのは危険だ。

前述の記事でなされている通り,Vimでgrep検索するときに発生するイベントであるquickfixをautocmdで捕捉する。:vimgrepを使うときだけwildignoreで検索対象外ファイルをsetlocalで追加設定し,grep検索が終了したらすぐにwildignoreで追加した項目を除外するのがよいだろう。

例えば,以下のように設定することになるだろう。

autocmd QuickFixCmdPre *
\ setlocal wildignore+=*.o,*.obj,*.exe,*.dll,*.bin,*.so,*.a,*.out,*.jar,*.pak
\| setlocal wildignore+=*.zip,*gz,*.xz,*.bz2,*.7z,*.lha,*.deb,*.rpm
\| setlocal wildignore+=*.pdf,*.png,*.jpg,*.gif,*.bmp,*.doc*,*.xls*,*.ppt*

autocmd QuickFixCmdPost *
\ setlocal wildignore-=*.o,*.obj,*.exe,*.dll,*.bin,*.so,*.a,*.out,*.jar,*.pak
\| setlocal wildignore-=*.zip,*gz,*.xz,*.bz2,*.7z,*.lha,*.deb,*.rpm
\| setlocal wildignore-=*.pdf,*.png,*.jpg,*.gif,*.bmp,*.doc*,*.xls*,*.ppt*
Vim script構文を使ったスマートな設定方法

上記で一応設定できたが,この書き方だと,Vimのgrepでの検索前後であるQuickFixCmdPreQuickFixCmdPostとで,2回wildignoreを設定する必要がある。片方への書き忘れがあったり,検索対象外ファイルが増えてきたら行数が増えるので,賢いやり方ではないだろう。Vim scriptの構文を少し使えばスマートに設定できる。

以下の通りに,スクリプトローカル変数s:ignore_listに検索対象外ファイルを記述し,executeで文字列を実行してやれば検索対象外ファイルの記述の重複がなくなる。それに加えて,古いVimではwildignroeが使えないこともあるので,Vimのwildignore機能が有効なときだけwildignoreを設定するようにすれば完璧だろう。

"" vim grep
""" ignored files in vimgrep
let s:ignore_list = ',.git/**,.svn/**,obj/**'
let s:ignore_list .= ',tags,GTAGS,GRTAGS,GPATH'
let s:ignore_list .= ',*.o,*.obj,*.exe,*.dll,*.bin,*.so,*.a,*.out,*.jar,*.pak'
let s:ignore_list .= ',*.zip,*gz,*.xz,*.bz2,*.7z,*.lha,*.lzh,*.deb,*.rpm,*.iso'
let s:ignore_list .= ',*.pdf,*.png,*.jp*,*.gif,*.bmp,*.mp*'
let s:ignore_list .= ',*.od*,*.doc*,*.xls*,*.ppt*'

if exists('+wildignore')
autocmd QuickFixCmdPre * execute 'setlocal wildignore+=' . s:ignore_list
autocmd QuickFixCmdPost * execute 'setlocal wildignore-=' . s:ignore_list
endif
vimgrepで気づいたこと

Vimの内部grepである:vimgrepを試していて気づいたことがあるので参考までに記載しておく。

Linuxのgrepコマンドでは,とくに指定なければ,検索対象ファイルに隠しファイル.*を含めて再帰的に検索すると,1階層上を示す..が検索対象ディレクトリにヒットしてしまい,ファイルシステム全体を検索することになって危険だった。

grep -r "pattern" .* *

これを防ぐには,正規表現で..を除外させるか,オプション--exclude-dir..を除外すれば回避できた(参考:My Future Sight for Past: How to match grep command for all files including hidden files)。

grep -r "pattern" .[!.]* *
grep -r "pattern" .* * --exlucde-dir=..

しかし,:vimgrepでは以下の通りに検索してもヒットするのは1階層上のディレクトリ配下までであり,ファイルシステム全体を検索してしまうようなことはなかった。:vimgrepの方がgrepコマンドより安全にできているのかもしれない。

:vimgrep 'pattern' .**/
外部grep(:grep)

外部grep(:grep)でバイナリーファイルやディレクトリを検索対象外にするには,grepprgを設定する。grepprgは外部grepを使うときに実際に実行されるコマンドとオプションとなっている(参考:grepprg - options - Vim日本語ドキュメント)。

grepprgの既定値はOSごとに以下となっている。

grepprgの既定値
OS既定値
Unix"grep -n $* /dev/null"
Win32"findstr /n""grep -n"

このように,OSごとに使われるコマンドが異なるので,設定を分岐させる必要がある。grepコマンドはPOSIXでも規定されており,LinuxやMac,WindowsにおいてもCygwinやMSYS2など使える可能性が高い。そこで,grepコマンドが存在すれば,grepコマンドのオプションとして設定し,そうでなければWindowsとみなしてfindstrコマンドのオプションとして設定するのがよいだろう。

if executable('grep')
set grepprg=grep\ -n
else
set grepprg=findstr\ /n\ /p
endif
findstr(Windows)の設定

Windowsでは標準で外部grepコマンドにfindstrコマンドが使われる。

このコマンドはWindowsにおけるgrepコマンドに相当するもので,正規表現を使ってファイル内の文字列を検索できる。しかし,grepと異なり検索対象外のファイルやディレクトリやを設定することはできない。

しかし,/pオプションをつけることで,バイナリファイルを検索対象外ファイルに指定できる。したがって,grepprgには以下のとおりに設定するのが最善だろう。

set grepprg=findstr\ /n\ /p

その他,findstrコマンドではディレクトリを再帰的に検索するのに/sオプションを使うなど,grepとはコマンドの体系が異なっている。ヘルプを確認して使い方を習熟しておく必要があるだろう。

個人的には,findstrコマンドを使うくらいなら,コマンド体系を統一できる内部grepである:vimgrepコマンドを優先したい。

GNU grepコマンドのオプション

Windows以外であれば,基本的には外部grep(:grep)にはgrepコマンドが使われる。POSIXで規定されているgrepには検索対象外のファイルやディレクトリを指定できないが,多くの環境で使われていると思われるGNU grepであれば,オプションが用意されている(参照:Man page of GREP)。

GNU grepで検索対象外に関するオプション
オプション説明
--binary-files=without-match, -Iバイナリーファイルを無視する。
--exclude-dir指定したディレクトリを無視する。
--exclude指定したファイルを無視する。ファイルはパスなしのファイル名であるベースネームのみで判定する。

--exclude-dirと--exludeではマッチングにglobまたはワイルドカードとして,*?[...]が使える。また,一度に複数の項目を設定するには,値を波括弧{}で囲み,項目はカンマ,で区切る。または,--exclude-dirなどのオプションを複数回繰り返して指定してもよい。ただし,波括弧で囲めるのは値が複数個あるときだけ。1個しかないのに波括弧を使うと,その設定は無視される。値はでも有効なので,をつけよう。なお,波括弧を引用符で囲むと波括弧自体が文字列として解釈されるので注意しよう。


grep "pattern" * --exclude-dir={..,.git}
grep "pattern" * --exclude-dir=.. --exclude-dir=.git
grep "pattern" * --exclude-dir={..} # これは無視される
grep "pattern" * --exclude-dir={,..} # これはOK
grep "pattern" * --exclude-dir="{,..}" # これはNG

例えば,以下のように設定すればよいだろう。

set grepprg=grep\ -n\ -I\ --exlucde-dir={..,.git,.svn,.obj} --exclude={tags,GTAGS,RTAGS,GPATH}

なお,--exclude-dirオプションはGNU grep 2.5.2から導入されたらしく,それ以前のgrepでは--excludeを使えば代用できるとの情報を見かけた(参考:grepで.svnディレクトリを除外して再帰検索 - 日々の報告書)。しかし,--exclude=*.svnなどとしてもディレクトリを除外できなかったので,2.5.2以降のバージョンでは--excludeオプションの仕様が変わったのかもしれない。

Unixでのgrepprgの既定値の/dev/null

Unixでのgrepprgの既定値は,以下となっている(参考:grepprg - options - Vim日本語ドキュメント)。

grepprg=grep\ -n\ $*\ /dev/null

grepでは検索対象を指定しなければ,標準入力から読み込まれるとみなされ動作が停止してかのようにみえてしまう。Unixだけ後ろに$*\ /dev/nullが付いているのは,検索対象の指定を忘れたときの予防のためだろう。検索対象に/dev/nullが指定されるようにすることで,標準入力からの入力を待ち続けることを回避できる。

しかし,この指定があると通常のgrepと挙動が変わってくる。それは,-rオプションで再帰的にディレクトリを指定するときだ。

echo "backup"> a.sh
## これはヒット
grep -r --include=*.sh backup

## vim
vim
## これはヒットしない
:grep -r --include=*.sh backup

grepprg=grep\ -n\ $*\ /dev/nullとなっていれば,ディレクトリに/dev/nullが指定されたとみなされ,現在ディレクトリを探しにいかない(参考: Differences when using grep in terminal and :grep in vim - Stack Overflow)。

この問題を避けるためにも,grepprgの既定値から$*\ /dev/nullを削除した。また,次の節で説明するが:grepの実行後のQuickFix-Windowにおいて,ステータスラインに表示されるスペースを省略するためにも有効だ。
Vimの外部grep(:grep)とシェルのgrepコマンドのオプションの共通化

grepprgの値としてgrepコマンドを使う時の設定例として以下を掲載した。

set grepprg=grep\ -n\ -I\ --exlucde-dir={..,.git,.svn,.obj} --exclude={tags,GTAGS,RTAGS,GPATH}

これには以下2点の問題がある。

  1. :grep実行後のQuickFix-Windowでのステータスラインの逼迫。
  2. 通常のgrepコマンドとVimの外部grepとで設定の重複。

1.の:grep実行後のステータスラインが逼迫されることについて説明する。

:grepを実行後のQuickFix-Windowでは,検索コマンドがステータスラインに表示される。しかし,grepprgが長いと画面に入りきらず,一部が省略されて表示されてしまう。例えば以下の画像のように先頭部分が>で省略されてしまっている。見た感じが悪いのでできれば回避したい。

2.について説明する。基本的には検索対象外ファイルの設定は通常のgrepコマンドでもVimの:grepでも同じ設定になるはずだ。片方の設定忘れなど保守が悪いので,共通化したい。

この2点の問題を解決する方法がある。それは,以下だ。

grepにオプションを追加したaliasを設定しておいて,vimから使えるようにする。

こうすれば,Vimのgrepprgで設定する必要がなくなりbashなどと設定を共通化できる。また,ステータスラインの表示スペースも節約できる。

Vimからシェルのaliasを使う方法は「My Future Sight for Past: Use of alias for Vim external command」に詳しくまとめている。

例えば,~/.bashenvファイル(~/.bashrcでも可)に共通設定を記入を記入しておき,そのファイルをVim起動中に環境変数BASH_ENVに設定する。

## .bashenv

## grep 2.21 later, deprecated GREP_OPTIONS environmental variable
GREP_OPTIONS="--color=auto -I --exclude-dir={.,..,.git,.svn,obj}"
GREP_OPTIONS="${GREP_OPTIONS} --exclude={tags,GTAGS,GRTAGS,GPATH}"
alias grep="grep ${GREP_OPTIONS}"
## .vimrc

if executable('grep')
""シェルと共通化させない場合の設定
" set grepprg=grep\ -n\ -I\ --exlucde-dir={..,.git,.svn,.obj} --exclude={tags,GTAGS,GRTAGS,GPATH}
set grepprg=grep\ -n
else
"" for Windows
set grepprg=findstr\ /n\ /p
endif

"" Enable alias for external command
if filereadable(glob('~/.bashenv')) | let $BASH_ENV=expand('~/.bashenv') | endif

こうすることで,grepのオプションをVimとシェルとで共通化でき,ステータスラインのスペースも確保できる。

まとめ

Vimの内部grep(:vimgrep)と外部grep(:grep)でバイナリーファイルや特定のディレクトリを検索対象外にする方法をまとめた。これでVimでファイルを検索するのが快適になるだろう。

最後に,今回の設定をまとめて掲載する。

## .vimrc

"" vim grep
""" ignored files in vimgrep
let s:ignore_list = ',.git/**,.svn/**,obj/**'
let s:ignore_list .= ',tags,GTAGS,GRTAGS,GPATH'
let s:ignore_list .= ',*.o,*.obj,*.exe,*.dll,*.bin,*.so,*.a,*.out,*.jar,*.pak'
let s:ignore_list .= ',*.zip,*gz,*.xz,*.bz2,*.7z,*.lha,*.lzh,*.deb,*.rpm,*.iso'
let s:ignore_list .= ',*.pdf,*.png,*.jp*,*.gif,*.bmp,*.mp*'
let s:ignore_list .= ',*.od*,*.doc*,*.xls*,*.ppt*'

if exists('+wildignore')
autocmd QuickFixCmdPre * execute 'setlocal wildignore+=' . s:ignore_list
autocmd QuickFixCmdPost * execute 'setlocal wildignore-=' . s:ignore_list
endif

if executable('grep')
""シェルと共通化させない場合の設定
" set grepprg=grep\ -n\ -I\ --exlucde-dir={..,.git,.svn,.obj} --exclude={tags,GTAGS,GRTAGS,GPATH}
set grepprg=grep\ -n
else
"" for Windows
set grepprg=findstr\ /n\ /p
endif

"" Enable alias for external command
if filereadable(glob('~/.bashenv')) | let $BASH_ENV=expand('~/.bashenv') | endif
## .bashenv

## grep 2.21 later, deprecated GREP_OPTIONS environmental variable
GREP_OPTIONS="--color=auto -I --exclude-dir={.,..,.git,.svn,obj}"
GREP_OPTIONS="${GREP_OPTIONS} --exclude={tags,GTAGS,GRTAGS,GPATH}"
alias grep="grep ${GREP_OPTIONS}"

Ubuntu 16.04でmozcが起動できない問題の対処

$
0
0

2016-06-04にUbuntu 16.04にアップグレードして1周間程度経過した。なぜかわからないが,急にIMEのmozcが起動しなくなり,日本語入力ができなくなってしまい困ってしまった。どうにか解決できたのでそのときの対処方法を記す。

PCにログインすればmozcは自動起動しているが,コマンドでも起動できる。mozcが動作しなくなったので以下のコマンドでmozcを起動させようとしたらエラーが出てしまった。

fcitx
(ERROR-7517 /build/fcitx-J2yftF/fcitx-4.2.9.1/src/lib/fcitx/instance.c:440)     + Exiting.   

半角/全角キーなどを押下してもIMEが切り替わらない。仕方がないので,一旦mozcを再インストールすることにした。以下のコマンドで再インストールした。

sudo aptitude reinstall fcitx-mozc

しかし,再インストールしても結果は変わらなかった。いろいろと操作をしていたら解決できた。

右上のタスクトレイのキーボードアイコンをクリック,またはターミナルから以下のコマンドを入力

fcitx-configtool

[Configure]>[+]>[Mozc]を選択

何らかの原因で,Input Method一覧からMozcが消えてしまったのが原因のようだった。ひとまず解決してよかった。

How to extract column field in shell script

$
0
0

シェルスクリプトで列フィールドの抽出方法をまとめた。

シェルスクリプトでCSVなど一覧表やログファイルを処理していると,先頭や末尾のフィールドを取得したいときがある。いくつか方法があるのでまとめた。

結論は以下となった。

  • 記述の簡潔さではawkが一番だが,実行速度は最下位。
  • 最速はシェル変数展開。
  • 記述の簡潔さと実効速度を考えると,ループ処理ではcutコマンドを使うのが妥当。

シェルスクリプトでファイルを1行ずつ処理するときは,以下の形式よく使う。

cat data.dat | while read -r line
do
# field_first=$(echo "$line" | [command])
# field_last=$(echo "$line" | [command])
done

この中で,変数lineに格納された1行文のデータから,それぞれのフィールドを取得して処理していく。

先頭からN番目のフィールドを取得するには,cutコマンドが簡単だ。しかし,cutコマンドでは末尾からN番目のフィールドにアクセスするためのオプションなどはない。

何かよい方法がないか調査し,最後に実行速度も検討した。以下の順番で記載していく。

  1. cut
  2. awk
  3. sed
  4. grep
  5. シェル変数展開
  6. 速度比較
  7. まとめ

まずは,サンプルデータを用意する。

echo "a,b,c"> data.dat

cut

cutコマンドは,先頭からN番目のフィールドを取得するのは簡単だが,末尾からN番目は事前に列数を取得しておかないといけない。

cut -d ',' -f 1                data.dat  # a

LASTCOL=$(($(head -n 1 data.dat | grep -o ',' | wc -l) + 1))
cut -d ',' -f $LASTCOL data.dat # c
cut -d ',' -f $((LASTCOL - 1)) data.dat # b

最初にLASTCOL変数に列数を格納している。grepで区切り文字を検索して,そのヒット数をwcでカウントしてそれを+1している。最初に変数を用意しないといけないが,悪くない方法だ。

POSIXに含まれていないrevコマンドを使っていいなら,もっとエレガントにできる。

rev data.dat | cut -d ',' -f 1 | rev  # c
rev data.dat | cut -d ',' -f 2 | rev # b

処理内容を言葉にすると以下となる。

  1. revコマンドで一度行を反転(フィールドも反転)。
  2. cutコマンドで先頭(もともと末尾)のフィールドを抽出。
  3. 最後に反転した文字列を元に戻す。

参照:bash - How to find the last field using 'cut'. Linux - Stack Overflow

awk

awkコマンドは記述が一番簡単だ。

awk -F ","'{print 1}'         data.dat  # a
awk -F ","'{print $NF}' data.dat # c
awk -F ","'{print $(NF-1)}' data.dat # b

NF変数に最後のフィールドが格納されているとのこと。一時変数を用意しなくて済むので一番簡単だろう。

sed

sedだとちょっと複雑になる。

sed 's/^\([^,]*\),.*$/\1/' data.dat  # a
sed 's/^.*,\([^,]*\)$/\1/' data.dat # c
sed 's/^.*,\(.*\),.*$/\1/' data.dat # b

少し複雑でわかりにくいので説明する。sedは最短マッチのためのオプションなどはないので,正規表現を工夫して自分で最短マッチさせる必要がある。

  • ,[^,]*$で区切り文字から行末までの最短マッチ,つまり最後のフィールドをマッチさせている。
  • \(\)で,マッチした部分をグループ化し,\1で参照している。これにより,最後のフィールドだけを出力させている。
  • 最後から1番目のフィールドを取得するには,マッチの部分を,\(.*\),.*$のように,行末の直前にフィールドを表す,.*をその回数分記述する。

複雑で,3番目などになると,記述が長くなるのでよい方法ではない。

grep

sedと同様に,grepでもパターンマッチを使うことでフィールドを抽出できる。

grep -o '^[^,]*' data.dat # a
grep -o '[^,]*$' data.dat # c

-oオプションでマッチ部分だけ出力できるので,sedよりは簡単にかける。

ただし,grepで先頭と末尾以外のN番目のフィールドを抽出するのは難しい。正規表現のパターンが思いつかなかった。

http://stackoverflow.com/a/22727242/4352571

シェル変数展開

最後に考えられるのは,シェル変数展開だ。

line=$(cat data.dat)
line_first="${line%%,*}" # a
line_last="${line##*,}" # c

line_first_1="${line#*,}"&& line_first_1="${line_first_1%%,*}" # b
line_last_1="${line%,*}"&& line_last_1="${line_last_1##*,}" # b

この方法だと,先頭か末尾のフィールドの取得は簡単だ。N番目は以下の手順を繰り返すことで習得できる。

  1. 一度先頭か末尾のフィールドだけを削除した変数(${line#*,}${line%,*})を用意。
  2. その変数に対して,先頭や末尾までのフィールドまでを削除(${line2%%,*}${line2##*,})。

シェル変数展開を使う場合,コマンドを間に挟まないため早い実行速度が期待できる。

http://stackoverflow.com/a/22727262/4352571

速度比較

列からフィールドを取得する方法をみてきたが,awkが最も簡単にできそうだ。しかし,フィールドからの値の取得は,ファイルなどのループでの利用が頻出事項と考えられる。実行速度も重要な項目だろう。

そこで,実際にここで紹介した方法で5万行のファイルを処理させて処理時間を計測・比較した。

計測に使用したスクリプトは以下となる(Gist)。

cat <<- EOF > loop-time.sh
#!/bin/sh
# \file loop-time.sh
# \author SENOO, Ken
# \copyright CC0

set -u
DATA="loop-data.dat"
: > $DATA
for i in $(seq 1 50000)
do
echo "1,2,3,4,5,6,7,8,9,0">> $DATA
done

timeit_loop(){
start=$(date +%s)
cat $DATA |
(
while read -r line
do
last_field="$(eval $1)"
done
end=$(date +%s)
dt=$((end - start))
echo "time: $dt [s], last field: ${last_field}, $1"
)
}

LASTCOL=$(($(head -n 1 $DATA | grep -o ',' | wc -l) + 1))

timeit_loop 'echo "$line" | rev | cut -d ',' -f 1 | rev'
timeit_loop 'echo "$line" | cut -d ',' -f $LASTCOL'
timeit_loop 'echo "$line" | awk -F ",""{print \$NF}"'
timeit_loop 'echo "$line" | grep -o [^,]*$'
timeit_loop 'echo "$line" | sed "s/^.*,\([^,]*\)$/\1/"'
timeit_loop 'echo ${line##*,}'
EOF

これを実行させると以下となる。

./loop-time.sh | sort
time: 37 [s], last field: 0,  echo "$line" | cut -d , -f $LASTCOL
time: 50 [s], last field: 0, echo "$line" | grep -o [^,]*$
time: 51 [s], last field: 0, echo "$line" | sed "s/^.*,\([^,]*\)$//"
time: 54 [s], last field: 0, echo "$line" | rev | cut -d , -f 1 | rev
time: 71 [s], last field: 0, echo "$line" | awk -F ",""{print \$NF}"
time: 8 [s], last field: 0, echo ${line##*,}

コマンド実行が少ないシェル変数展開が8 sと最速となった。次点は37 sのcutコマンド単体となった。それ以降は,grep,sed,cut+revが並んでおり,awkが71 sと最下位となった。

cut+revコマンドは使用するコマンド数が3個と最も多いことから,処理速度が遅くなることを心配したが,そこまで遅くなかった。用途が特化している分,実行速度が最適化されているのだろう。

まとめ

シェルスクリプトで列フィールドを取得する方法をまとめた。結論は以下となった。

  • 記述の簡潔さではawkが一番だが,実行速度は最下位。
  • 最速はシェル変数展開。
  • 記述の簡潔さと実効速度を考えると,ループ処理ではcutコマンドを使うのが妥当。

記述の簡潔さからawkが一番かなと思ったが,実行速度をみるとそうともいえなかった。ループ中でawkでフィールドを取得するのは控え,シェル変数展開の活用を念頭に置き,難しそうならcutコマンド単体やcut+revコマンドの組み合わせが簡単だろう。

逆に,ループ外であれば実行速度はあまり問題にならないので,awkを使うのもよいだろう。

もともと,実行速度は調査するつもりはなく,awkが一番というありきたりな結論で終わりそうだった。今回速度を計測することで,予想外の結果となり勉強になった。時間の計測は大事だと思った。

How to install fonts on Linux

$
0
0

Linuxでフォントをインストールする方法はいくつかある。手動でインストールするにあたっては,Linuxでのフォント管理のライブラリであるFontconfigの設定ファイルについても知っておく必要がある。この記事では以下の順番で内容を記していく。

  1. パッケージマネージャーを利用
  2. フォントビューアーでインストール
  3. 手動でインストール
  4. Fontconfigの設定
  5. まとめ

動作はUbuntu 16.04で確認した。他のディストリビューションでも大きな違いはないと思われる。

結論として,ユーザーが手動でインストールする場合,以下の場所にフォントファイルを配置すればよい。

システム全体
/usr/local/share/fonts/
ユーザー専用
~/.local/share/fonts/

パッケージマネージャーを利用

多くの場合,パッケージマネージャーでコマンドなどのパッケージをインストールするのと同じようにフォントもインストールできる。例えば,Ubuntu 16.04ではaptコマンドでfontと検索するとフォントがヒットする。

apt search font

フォント名がわかっていれば,フォント名で検索してもよい。

apt search takao
Sorting... Done
Full Text Search... Done
fonts-takao/xenial,xenial 003.02.01-9ubuntu3 all
Japanese TrueType font set, Takao Fonts

fonts-takao-gothic/xenial,xenial,now 003.02.01-9ubuntu3 all [installed]
Japanese TrueType font set, Takao Gothic Fonts

fonts-takao-mincho/xenial,xenial,now 003.02.01-9ubuntu3 all [installed]
Japanese TrueType font set, Takao Mincho Fonts

fonts-takao-pgothic/xenial,xenial,now 003.02.01-9ubuntu3 all [installed]
Japanese TrueType font set, Takao P Gothic Fonts

パッケージ名がわかれば,インストールできる。

sudo apt install fonts-takao

フォントビューアーでインストール

パッケージマネージャーで提供されていないフォントや,最新のフォントをインストールする場合は,自分でフォントファイルからインストールする。自分でインストールする場合には,以下の2通りの方法がある。

  1. フォントビューアーを利用。
  2. 手動でフォントを配置。

ここでは,1. のフォントビューアーでインストールする方法を記す。

デスクトップLinuxではgnome-font-viewerコマンド(Font Viewer)が使える。Ubuntu 16.04ではDashからfont viewerで検索すればヒットする。

フォントビューアーでフォントをインストールする手順を示す。サンプルとして,あおぞら明朝フォントを利用する。

  1. gnome-font-viewerコマンドにフォントファイルを指定して実行。または,ファイルマネージャー(Nautilusなど)からフォントファイルを右クリック>[Open With]>[Font Viewer]から起動。
    gnome-font-viewer AozoraMincho-bold.ttf

  2. ウィンドウの右上の[install]をクリックするとインストールされる。

  3. フォントは$XDG_DATA_HOME変数が設定されていれば,$XDG_DATA_HOME/fontsに,設定されていなければ,~/.local/share/fonts/にインストールされる。

フォントビューアーを使ったフォントのインストールでは以下2点の問題がある。

  • デスクトップの無い,サーバーでフォントをインストールできない。
  • システム全体にフォントをインストールできない。

この問題を解決するには,自分で手動でフォントをインストールする必要がある。

手動でインストール

手動でインストールする際には,用途に応じて以下のどちらかのディレクトリにフォントファイルを配置すればよい。

システム全体
/usr/local/share/fonts/
ユーザー専用
~/.local/share/fonts/

fontsディレクトリの下にさらにフォント名のディレクトリを作っても問題ない。

mkdir ~/.local/share/fonts/Aozora/
cp Aozora*.ttf ~/.local/share/fonts/Aozora/

基本的にはこれだけでフォントが有効になる。万が一フォントが選べなければ,以下のコマンドでキャッシュを更新する。

fc-cache -f

Fontconfigの設定

手動でインストールするにあたって,Linuxでのフォント管理の仕組みについて調べたので記しておく。

Linuxでのフォントの管理には,Fontconfigというライブラリーを使っている。Fontconfigのマニュアルは以下のコマンドで確認できる。

man font-conf

fontconfigとセットでインストールされるコマンドのマニュアルの末尾(例:man fc-list)を見るとわかる通り,/etc/share/doc/fontconfig/fontconfig-user.htmlにもマニュアルが配置されている。また,最新のマニュアルを公式サイトでも確認できる。

Fontconfigの設定ファイル

マニュアルにかかれている通り,fontconfigの設定ファイルは以下となっている。

   /etc/fonts/fonts.conf
/etc/fonts/fonts.dtd
/etc/fonts/conf.d
$XDG_CONFIG_HOME/fontconfig/conf.d
$XDG_CONFIG_HOME/fontconfig/fonts.conf
~/.fonts.conf.d
~/.fonts.conf

設定ファイルがたくさんあるが,注目すべきは/etc/fonts/fonts.confだけだ。$XDG_CONFIG_HOME~から始まるファイルは存在しないことがあるからだ。

  • 最後の~/.fonts.conf.d~/.fonts.confは廃止予定となっている([Files]セクション参照)。
  • 真ん中の$XDG_CONFIG_HOMEから始まる設定ファイルは存在しないことがある。XDG_CONFIG_HOME変数は指定されていなければ,$HOME/.configを指す(参照:XDG Base Directory Specification)。Ubuntu 16.04では存在しなかった。
フォントのインストールディレクトリ

/etc/fonts/fonts.confを確認するとフォントのインストール場所が書かれている。

<!-- Font directory list -->

<dir>/usr/share/fonts</dir>
<dir>/usr/local/share/fonts</dir>
<dir prefix="xdg">fonts</dir>
<!-- the following element will be removed in the future -->
<dir>~/.fonts</dir>

マニュアルの[Configuration File Format]セクションを確認するとわかるが,<dir prefix="xdg">と書かれている要素は,環境変数XDG_DATA_HOMEで指定されているディレクトリを指す。そして,XDG_DATA_HOME環境変数は基本的には空となっており,空の場合は$HOME/.local/shareを指す。(参照:XDG Base Directory Specification)。

これらを考慮すると,Linuxでのフォントのインストール場所と役割は以下となる。

Linuxでのフォントインストール場所
ディレクトリ説明
/usr/share/fontsシステム全体フォント(パッケージマネージャー用)。
/usr/local/share/fontsシステム全体フォント(ユーザーカスタマイズ)。
$XDG_DATA_HOME/fonts(~/.local/share/fonts)ユーザー用フォント。
~/.fontsユーザー用フォント。廃止予定。

ここで,注意したいのは~/.fontsディレクトリだ。ネット上での記事をみると,未だに~/.fontsにフォントをインストールしているものがたくさんでてくる。しかし,~/.fontsは廃止予定なので,このディレクトリーにフォントを配置すべきではない。

Fontconfigの付属コマンド

fontconfig には、フォント設定を管理する8つのコマンドラインユーティリティが付属している:

  • fc-list: fontconfigが把握しているすべてのフォントまたはパターンにマッチするすべてのフォントの一覧を表示する。
  • fc-match: fontconfigのマッチングルールに従ってフォントパターン(デフォルトで空のパターン)のマッチングを行い、利用可能なフォントのうち最も適切なものを見つける。
  • fc-cache: 指定されたディレクトリまたは設定ファイルで指定されたすべてのディレクトリから、FreeTypeが扱えるすべて
  • のフォントのキャッシュを作成する。
  • fc-cat: キャッシュファイルまたはフォントディレクトリからフォント情報を読み込み、それをASCII 形式で出力する。
  • fc-query: フォントファイルについて問い合わせ、結果を表示する。
  • fc-scan: フォントファイルまたはディレクトリをスキャンし、結果を表示する。
  • fc-pattern: 指定したパターンに最も近いフォントを表示する。
  • fc-validate: フォントファイルを検証し、結果を表示する。

Fontconfig - Wikipedia

上記のコマンドでよく使うのは,fc-listfc-cacheだ。fc-listで現在インストールされているフォントを確認できる。フォントをインストールして,認識されなかったらfc-cacheコマンドでキャッシュを更新する。

まとめ

Linuxでのフォントのインストール方法をまとめた。このまとめで,Linuxでのフォントインストール方法は完璧だろう。Ubuntu 16.04で動作を確認したが,CentOSやDebianなど他のディストリビューションでも基本は同じだろう。

ネット上の記事では~/.fontsにインストールしているものが多く,~/.local/share/fontsとどちらにインストールしたらいいかわからなかった。また,~/.local/share/fontsが設定ファイルのどこで指定されているのか,根拠を見つけるのに時間がかかってしまった。結局のところ,設定ファイル/etc/fonts/fonts/confに全て情報が書かれていた。一時情報に当たることはやはり重要だ。

参考:UbuntuTips/Desktop/InstallFont - Ubuntu Japanese Wiki

第24回参議院通常選挙で「三宅洋平」と「支持政党なし」に投票した理由

$
0
0

2016-07-10に参議院選挙があった。選挙区には三宅洋平,比例代表には「支持政党なし」に投票したので,その理由について書いた。

結論を簡単に述べると以下のとおりだ。

三宅洋平の理由
  1. 候補者中最大の動物愛護政策。
  2. 演説の熱さと内容への共感。
支持政党なしの理由
  1. 自分の関心に対する政策を掲げている党の不在。
  2. 政策一切なしという方針と与党以外無意味との自覚の潔さ。

目次

  1. 背景
  2. 支持の方針
  3. 選挙区
  4. 比例代表
  5. まとめ

背景

今回の選挙は選挙権年齢が「満20歳以上」から「満18歳以上」に引き下げられた初の選挙ということもあり,注目度の高い選挙となったと思う。ニュースなどでは憲法改正が一つのキーワードだったようで,憲法改正について議論があった印象だった。

僕は今27歳なので,既に数回投票したことはある。今まであまりよく考えずに投票していて,無責任だなと自分で思っていた。以下3点の理由から,誰にどんな理由で投票したかを公表することにした。

  1. 成人してから7年の時間経過。
  2. 自分の中の正義のさらなる確立。
  3. 自分の選択への責任。

僕は東京都に在住しているので,今回の選挙では,東京都の選挙区と比例代表の2候補を選択することになる。それぞれについて,誰にどんな理由で投票したかを説明する。

説明の前に,今回の選挙で重要な資料となる選挙広報が東京都選挙管理委員会から公開されている。この選挙公報はポストに投函され,有権者全員が平等に参照できるもので,とても大きな参考資料にした。

選挙が終わるとサイトごと公開が停止される可能性が高いので,僕のGoogle Driveでも公開しておく。

支持の方針

まず,投票にあたって何を重要視するか考えた。政治の問題は範囲が広く一つ一つの内容も難しい。わからないことをあれこれ考えてもしかたない。そこで,自分の目指す目標と近いかどうかで判断することにした。具体的には,自分の正義を通すために関心を持っている以下の項目だ。

  • 自由ソフト
  • オープンデータ
  • 組版
  • 数値解析
  • 動物愛護

これらのキーワードに関連する政策や公約を選挙公報で掲げているかどうかを支持の重要判断材料とした。

選挙区

この視点で選挙公報を読むと,動物愛護以外の項目については誰一人として言及していなかった。

そして,動物愛護について言及していたのは3人だけだった。立候補者と選挙公報における言及箇所を以下の表に示した。

動物愛護の政策を掲げた立候補者
立候補者名選挙公報の該当箇所(赤枠)該当テキスト抜粋
三宅洋平

◎環境第一(憲法に生態系の権利を)

◎動物殺処分0!

◎オーガニック革命(有機・自然農の推進)

◎1億万耕(農教育の制度化)

田中康夫

5 愛するペットの殺処分ゼロを目指します!

お隣の神奈川県では犬と猫の殺処分ゼロを3年連続で達成。家族に一員である皆さんの愛犬・愛猫の体内に、マイクロチップ装着を義務付ける取り組みを勧めます。

福島みずほ

[政策・得意分野]

平和、女性、人権、脱原発、雇用、経済、犬猫殺処分ゼロ

選挙公報を見てわかるとおり,三宅洋平が動物愛護に関して一番政策をもっている

三宅洋平は犬猫に限定せず,「動物殺処分0!」と掲げている。また,動物を大量に殺している畜産部門についても,オーガニックを推進すると掲げている。東京都の選挙区には31人立候補していたが,三宅洋平以上に動物愛護に関する政策を挙げている立候補者はいなかった。

三宅洋平の存在は動物愛護のブログ記事「飲食店業界はベクレルフリーを常識に。「ノンベクキッチン・ホテヴィラでVEGANごはん♪」参院選は三宅洋平さんを応援♪ #京都ベジレス情報 - 未分類」で初めて知った。動物愛護の人も支持しており,興味を持った。

しかし,山本太郎や「生活の党と山本太郎となかまたち」が推薦しているということで,印象は悪かった。というのも,山本太郎や小沢一郎という人物と彼らが在籍する生活の党が胡散臭かったからだ。そこで,毎週土曜日18:00-20:00に渋谷のハチ公園前でやっているという選挙フェスで演説を聴講して最終判断することにした。

以下のツイートに示す通り,結局は渋谷ではなく品川駅ということで19:30頃に到着して20分ほど演説を聴講できた。

そのときの演説をきいた感想が以下のツイート群だ。

熱い人だという噂をきいてはいたが思っていた以上に熱い人だった。細かいことはわからないが素直にいいと思った。

以上のことから,以下2点の理由で三宅洋平に投票にした。

  1. 候補者中最大の動物愛護政策。
  2. 演説の熱さと内容への共感。

比例代表

続いて残りの比例代表を検討した。比例代表は個人ではなく,政党を信じて投票する制度だ。既に見たとおり,選挙公報で動物愛護について掲げているのは3人の立候補者だけで,政党として掲げているところはなかった。三宅洋平は無所属での立候補であり,山本太郎や小沢一郎の所属する「生活の党と山本太郎となかまたち」の疑いが晴れたわけではない。だから,比例代表をどの政党に投票するかは悩んでいた。

選挙公報を眺めていると,見慣れない名前の政党が目に留まった。その政党は「支持政党なし」というものだ。選挙公報は以下のとおりだ。


「生活の党と山本太郎となかまたち」という政党名もふざけた名前だが,それに負けじ劣らない政党名で驚いた。なんでも党としての政策は一切持たず,ネットで意見を募集してそれを元に国会質疑や法案可否選挙を投票するというものだ。

それで,この「支持政党なし」にたいして興味を示すツイートをすると,警告をもらった。

よくしらなかったので,そのときはそうなのかなと思った。選挙前日になって調べてみると,この人の指摘は勘違いだということがわかった。「支持政党なし」が自民党を支持しているというのは,おそらく以下の党代表の佐野秀光のブログ記事の以下の文を読んでのことだろう。

そもそもが今の国会をみれば誰だって解るのは、与党の自民党と公明党の言う政策以外は、全て絵に描いた餅ですからね💥💥💥💥💥💥💥💥

『新党本質』⇒『安楽死党』⇒『支持政党なし』代表 佐野秀光の日常: 正直な政党

ここだけをみると,「自民党と公明党の政策以外意味がない=自公支持」と解釈できなくもない。そう解釈して残念だというコメントが残っていた。

面白いと思っていたのに「自民党と公明党の言う政策以外は、全て絵に描いた餅」というお話は残念でした。支持政党なしが支持政党ありというのは悲しいです。間接的にせよ党派色のある発言は約束違反ではないでしょうか。
Posted by 諏訪山よしお at 2016年07月01日 01:10

しかし,これはご解釈だ。これを裏付ける,コメントのやりとりが残っていた。

現状の国会の議席数を見ますと、支持政党なしが仮に全員当選しても、与党のやることを止める事は出来ませんが、せめて皆さん方の意見を集約して反対票を入れる事は出来ると言う現実的な意見でございます。

>諏訪山よしおさん
>
>面白いと思っていたのに「自民党と公明党の言う政策以外は、全て絵に描いた餅」というお話は残念でした。支持政党なしが支持政党ありというのは悲しいです。間接的にせよ党派色のある発言は約束違反ではないでしょうか。
Posted by ヒデミツ at 2016年07月01日 09:31

最初のブログの記事だけでは意味が見えにくかったのですが、コメント欄のやり取りを見て、理解できたような気がします。

つまり、「絵に描いた餅」という表現は、別に「現在の与党に賛成」という意味ではなく、単に「国会で多数を占めない政党(野党)が、どんな政策を提言しても、多数決の下では、実現できない」という意味で言ったということですか?

それで、「立候補者が全員当選しても、与党になれない以上は、政策を提言しても、『絵にかいた餅』になってしまうため、『政策無し』と言ってる」ということでしょうか?

そして、将来的に勢力が拡大し、与党になれるくらいの立候補者数を擁立する場合には、「絵に描いた餅」ではなく、実現可能性が出てくるため、インターネット上で意見を取りまとめて、政策を提言するということでしょうか?

Posted by 通りすがり at 2016年07月02日 12:23

つまり,「与党の自民党と公明党の言う政策以外は、全て絵に描いた餅」というのは,多数決が全ての民主主義の投票では,過半数の議席を持つ自民党と公明党以外の政党の政策は通ることがなく意味がないということだ。

このことを受けて支持政党なしについて考えてみた。

結論をまとめると,以下2点の理由から支持政党なしに投票した。

  1. 自分の関心に対する政策を掲げている党の不在。
  2. 政策一切なしという方針と与党以外無意味との自覚の潔さ。

まとめ

まとめると,冒頭にも記載したとおり,三宅洋平と支持政党なしに投票した理由は以下のとおりとなる。

三宅洋平の理由
  1. 候補者中最大の動物愛護政策。
  2. 演説の熱さと内容への共感。
支持政党なしの理由
  1. 自分の関心に対する政策を掲げている党の不在。
  2. 政策一切なしという方針と与党以外無意味との自覚の潔さ。

今回の選挙は,今まで一番誰を選ぶか考えて投票した選挙だった。自分の正義に基づいて,論理的に選ぶことができてとても納得のいく投票ができた。

ただ,残念なことに,選挙速報を見る限り,三宅洋平も支持政党なしも結局のところ落選してしまったようだ。

自分の正義をより確立するためにも,今後も誰にどういう理由で投票したか公開していきたい。


@ツイートを無効化する方法

$
0
0

Twitterでツイートするときに,@に続けてユーザーIDを指定すると,指定したユーザーにメッセージが通知されるツイート(メンション,@ツイート)を送信できる。しかし,@の直前に特定の文字が登場すると,@ツイートとみなされず,通知がされなくなることを発見したので記録として残しておく。

公式サイトでの注意書き

公式サイトでは,以下のように@マークの直前に文字や数字があると,@ツイートは機能しないと書かれている。

 @マークの前に文字を入力していないか。たとえば「123@Support」または 「word@Support」と入力した場合、ツイートはSupportには届きません。@マークの前に文字や数字があると、@ツイートと@返信は正常に 機能しません。@ツイートが機能するには、@マークがツイートの先頭にあるか、@マークのすぐ前にスペースが挿入されている必要があります。

ハッシュタグや返信が正常に機能しない | Twitterヘルプセンター

しかし,具体的にどの文字が@ツイートを無効化してしまうのかは書かれていない。気になったので調べてみた。

@ツイートが有効であると,その部分が緑色のリンクになっていてクリックできる。無効化になっていると,通常のテキスト同じ黒色でリンクはない。

これはツイッターの公式ページからツイートするときや,ツイート自体で確認できる。例えば,以下のツイートでは-@senopenと+@senopenは@ツイートが有効であることが見てわかる。

無効化できる文字

キーボードから入力できる文字を試すと,@の直前に以下のいずれかの文字を配置すると直後の@ツイートを無効化できることがわかった。

!#*$%_
1234567890
abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ
style="font-family: sans-serif;">

言葉で説明すると以下のとおりとなる。

  • 半角の記号!$*$%
  • 半角の数字
  • 半角小文字の英字
  • 半角大文字の英字

なお,これら以外の記号(+-/\など)も全て試したが,@ツイートを無効化できなかった。当初は,ツイート画面で無効化になっていたように見えたので,&と@も@ツイートを無効化できると思っていた。しかし,実際のツイートでは@ツイートが有効になっていた。

@ツイートを意図的に無効化してもあまり意味はない。意味があるとすれば,以下2点だろうか。

  • スクリプトなどで自動でツイートするときに@ツイートが無効になることを事前に予防できる。
  • ツイートするときにこれらの文字を@ツイートを無効化してしまうことを知っていれば,意図せずに@ツイートが無効化されてしまうことを防げる。

役には立たないだろうが,あまりネット上にも情報はないようなので,豆知識として掲載した。

関連ツイート

以下に@ツイートを無効化する文字を発見したときのツイート郡を参考までに掲載しておく。

Install Adobe Flash Player plugin for Chromium on Ubuntu 16.04

$
0
0

Ubuntu 16.04のChromiumでAdobe Flash Playerのプラグインをインストールする方法を記す。

先日PCの調子が悪かったので,Ubuntu 16.04を再インストールした。一通り必要なソフトのインストールなどを終えて,以前と同じように作業できるようになっていた。Youtubeやニコニコ動画などで動画を閲覧しようとしたら,ブラウザーのChromiumにFlash Playerのプラグインがインストールされていなくて,閲覧できなかった。

確か,Ubuntu 14.04のときは,「Chromium で Flash Player が使えなくなる件の対処法 - Qiita」のページの手順にしたがって,以下のコマンドを実行して解決した記憶がある。

sudo apt install pepperflashplugin-nonfree
sudo update-pepperflashplugin-nonfree --install

Ubuntu 16.04では,この手順通りにコマンドを実行しても解決しなかった。仕方ないので,調査を続けると,以下のサイトの手順で解決した。

How can I install the flash player for Chromium in Ubuntu 16.04? - Ask Ubuntu

どうやら,Ubuntu 16.04からは以下の手順でCanonicalパートナーのレポジトリを追加すればaptからインストールできるようだ。

[System Settings]かunity-control-centerコマンドを実行→[Software & Updates]→[Other Software]タブ→[☑Canonical Partners]

リポジトリの追加ができたら以下のコマンドでAdobe Flash Playerのプラグインをインストールする。

sudo apt update
sudo apt install adobe-flashplugin

これでChromiumでYoutubeやニコニコ動画などの動画を視聴できるようになる。

Best coding font in Windows and Linux default font

$
0
0

LinuxとWindowsに標準でインストールされているフォントでプログラミングなどソースコードの表示(コーディング)に最も適しているフォントを紹介する。

結論としておすすめするフォントはOSと言語ごとに以下の表のとおりとなる。

おすすめコーディング用OS標準フォント
言語WindowsLinux
英語ConsolasDejaVu Sans Mono
日本語MS GothicTakaoGothic(Debian系),VL Gothic(RedHat系)

目次

  1. OS標準フォントにこだわる理由と注意点
  2. コーディングに適しているフォントの要件
  3. 視認性の確認方法
  4. Windows標準フォント
    1. Windows標準コーディング用日本語フォント
    2. Windows標準コーディング用英語フォント
  5. Linux標準フォント
    1. Linux標準フォントの一覧
    2. Linux標準コーディング用日本語フォント
    3. Linux標準コーディング用英語フォント
  6. まとめ

OS標準フォントにこだわる理由と注意点

自分でインストールしたフォントで書かれた文章には以下2点の問題がある。

  • そのフォントがインストールされていない環境では作成時と異なって表示される。
  • 他人のPCでフォントがインストールされていることを保証できない。

これを避けるためには,OSに標準で付属しているフォントを使うしかない。しかし,OSの標準フォントには以下2点の問題がある。

  • プラットフォーム共通のフォントは存在しない。つまり,LinuxとWindowsの標準フォントで共通のフォントは存在しない。
  • OSでインストールされている言語により,日本語フォントは存在しないことがありえる。

このため,LinuxとWindowsのプラットフォームごとに,標準で使うフォントとして英語と日本語の両方のフォントを検討する必要がある。

なお,表示用フォントとして英語と日本語を分けて表示できない場合ことがあり得る。この場合は,表示対象に日本語が含まれていれば日本語フォントを選択し,そうでないときだけ英語フォントを使うことになる。

なぜならば,英語フォントには日本語フォントが含まれていないので,日本語部分の表示が化ける可能性があるからだ。OSやソフト側で,自動的に適切な日本語フォントで表示してくれることもあるかもしれないが,この問題を避けるため,コーディング用フォントには英語部分も考慮された日本語フォントを使うのがよいだろう。

コーディングに適しているフォントの要件

普段であればフォントの違いはあまり問題にならない。しかし,プログラミングでソースコードを表示させると問題になることがある。それは,他の文字と区別がつきにくい文字があり,文字が違うとプログラムが動作しなくなるからだ。例えば変数名で使われているIと1を間違えたら,エラーになったり意図しない結果になるはずだ。そこで,コーディングに適したフォントを選ぶことが極めて重要となる。

コーディングに適したフォントとは,文字が他の文字と見間違わずに識別できるフォントだ。具体的には以下の文字が視認しやすいことがポイントとなる。

  1. 形が丸○に近い文字:数字の0,英大文字のO,Q,D,英小文字e,c,oなど。
    0OQDC@eco
  2. 形が鉛直線に近い文字:数字の1,英大文字のI,記号の|,!,\,/,英小文字のl,i,jなど。
    1Il|!/\ij
  3. 数字の23569に近い文字:数字の8と英大文字のB,記号の&,数字の5と英字のS,数字の2と英大文字のZなど。
    db69qgg
    B8&$S53
    zsZ2
  4. 連続するとつながって見える文字:riとn,vvとw,引用符2個''と二重引用符"など。
    rmnuvwUVNMW
    "''`
  5. 形が水平線に近い文字:ハイフン-,チルダ~,サーカムフレックス^。
    -~^

その他の論点としては,記号の形がある。

  • バックスラッシュ(\):円記号¥と斜線\
  • アスタリスク(*):星形と三本線
  • チルダ(~):上よりと中央
  • サーカムフレックス(^):上よりと中央
  • ドル記号($):1本線と2本線
  • アンパーサンド(&)
  • アットマーク(@)

また,フォントの種類として以下は不適である。

  • プロポーショナルフォント:iとmなど文字幅が異なり,1行の文字の位置が異なる。また,テキストエディターではフォントとして選択できないことがほとんど。
  • 明朝体,serif体フォント:全体的に線が細い。また,文字内で線の太さがまちまちになり見た目の均一性が損なわれる。

したがって,コーディング用フォントには,ゴシック体か等幅フォントのタイプライタ体(Monospace)が適切だ。

視認性の確認方法

実際に調べていくと,フォント候補がいくつか登場し,実際に目視確認で判断が必要となる。フォントの視認性の判断には以下の英数字と記号全種類を対象とした。

abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ
1234567890
!?#$%&=_~^|*+-/\
"'`<>[](){}.,:;@

これをGVimで表示させて確認する。GVimでの表示にあたって,以下のコマンドで背景とカーソルの色をなくした。

:highlight Normal guibg=White
:highlight CursorLine guibg=NONE
:highlight Cursor guibg=NONE

Windows標準フォント

Windows標準フォントでコーディングに適しているフォントを選定する。

Windowsの最新バージョンは10であるが,リリースされて時間が経過し広く普及しているのは7だと考えるので,Windows 7標準フォントから選ぶ。Windows 7標準フォントは以下のサイトで確認できる。

Fonts supplied with Windows 7

WindowsではMS Officeをインストールすると一緒にフォントもインストールされる。MS OfficeのインストールされていないWindowsマシンのほうが少ないので,これらのフォントも標準と考えてよい思われる。その際のMS OfficeのバージョンにはWindows 7と同時期にリリースされたMS Office 2007が適当だ。MS Office 2007をインストールすると付属するフォントは以下で掲載されている。

Office の各バージョンに付属するフォント - Office のサポート

MS Officeに付属するフォントではHGから始まる日本語フォントがインストールされるので,日本語フォントの選定においては選択肢が広がることになる。

Windows標準コーディング用日本語フォント

Windows標準の日本語フォントには,MS Gothicがある。さらに,MS OfficeをインストールするとHGGothicMとHGGothicEがインストールされる。HGGothicEはHGGothicMを太くしたフォントなので,実質的には2種類となる。

MS GothicとHGGothicMでフォントを表示させたものを以下に示した。

Windows標準の日本語フォントの比較

フォントを比較した考察は以下となる。

  • HGGothicMはMS Gothicと異なり,文字の線連続しており美しい。
  • HGGothicMでは数字の0と英大文字Oとの区別が難しい。

HGGothicMはMS Gothicよりきれいなので,できればこちらを採用したかったのだが,数字の0と英大文字Oとの区別が難しいという欠点がある。そのため,やむを得ないがWindows標準の日本語フォントにはMS Gothicを使うのがよいだろう。

Windows標準コーディング用英語フォント

英語フォントには,Windows標準フォントから,コーディング用フォントとしてよく名前を聞く以下の3フォントを試した。

  • Consolas
  • Courier New
  • Lucida Console

表示結果を以下に示す。

Windows標準の英語フォントの比較

フォントを比較した考察は以下となる。

  • Consolas以外はアスタリスクの形が星形。
  • Consolasだけ数字の0に斜線があり英大文字Oと区別しやすい。
  • 数字の1と英小文字lとの区別はLucida Consoleが一番しやすい。
  • 英大文字のQとドル記号$がCourier Newだけ汚い。

ConsolasとLucida Consoleは,数字の0と1がアルファベットのOとlが片方判断しやすいが,もう片方が判断しにくいので,判断が難しい。最終的には,以下の理由から,Windowsの英語フォントにはConsolasがいいと判断した。

  • アスタリスクの形が唯一三本線。
  • 数字の0と英大文字Oの区別がしやすい。
  • 数字の1と英小文字lの区別は難しいが,先端の角度からできなくはない。

Linux標準フォント

Linuxでの標準フォント選定にあたり注意することが一つある。それは,Linuxではディストリビューションによって標準フォントが異なることだ。例えば,Ubuntu 16.04では標準フォントにUbuntu Monoが存在するが,これはCentOS 7には存在しない。したがって,OSごとに対象フォントを一覧して,共通で存在しているフォントを検討する必要がある。しかし,Linuxディストリビューションは数が多く全てを調査するのはたいへんだ。そこで,Linuxディストリビューションの代表として,Debian系のUbuntu 16.04とRedHat系のCentOS 7を対象とした。

Linux標準フォントの一覧

Linuxにおける標準フォント一覧は以下のコマンドで確認できる。

fc-liststyle="font-family: serif;">

このリストからは,言語に応じて以下のキーワードがヒットするフォントが検討対象になりえる。

英語
mono
日本語
gothic,japan,jp

具体的にはそれぞれ以下のコマンドで対象フォントを確認できる。

fc-list | grep -i mono                      # 英語
fc-list | grep -i -e gothic -e japan -e jp # 日本語

なお,gothicで検索してもそれがすべて日本語とは限らない。検索結果でフォント名に日本語名が書かれているものが日本語フォントだ。例えば,以下の検索結果ではURW GothicとVL Gothicがヒットしている。しかし,URW Gothicは日本語のフォント名が存在していないので,日本語フォントではないことがわかる。

/usr/share/fonts/default/Type1/a010035l.pfb: URW Gothic L:style=Demi Oblique
/usr/share/fonts/vlgothic/VL-Gothic-Regular.ttf: VL ゴシック,VL Gothic:style=regular

同様に,monoで検索して英語以外のフォント名の入っているフォントは英語フォントではないことがわかる。ただし,これには例外がある。Nogo Sans Mono CJK JPというフォントがあるが,これは英語名しかなく,Gothicともつかないが日本語を表示できるフォントだ。

実際にこの方法でまずは標準フォントを確認した。

CentOS 7で検索した結果,CentOS 7での英語と日本語の標準フォントは以下となることがわかった。

英語
  • DejaVu Sans Mono
  • FreeMono
  • Liberation Mono
  • Nimbus Mono L
日本語
  • VL Gothic

Ubuntu 16.04 で検索した結果,Ubuntu 16.04での英語と日本語の標準フォントは以下となることがわかった。

英語
  • DejaVu Sans Mono
  • FreeMono
  • Liberation Mono
  • Nimbus Mono L
日本語
  • Noto Sans Mono CJK JP
  • TakaoGothic
  • Ume Gothic
Linux標準コーディング用日本語フォント

CentOS 7での日本語のフォントはVL Gothicしか該当しなかった。

Ubuntu 16.04では日本語フォントが3種類存在していた。しかし,この中でTakaoGothic以外のフォントはUbuntu 10.04ではインストールされておらず,比較的最近搭載されるようになった。

2010年2月19日号 10.04の開発進捗・2D UNEランチャー・日本語フォントの変更・Ubuntu Global Jam・UWN#180:Ubuntu Weekly Topics|gihyo.jp … 技術評論社

互換性やその他のディストリビューションでの利用可能性を考えると,TakaoGothicが妥当だろう。

これらのことから,Linux標準コーディング用日本語フォントしては,VL GothicとTakaoGothicが適切だ。

Linux標準コーディング用英語フォント

英語フォントはCentOS 7とUbuntu 16.04で共通して以下の4種類がヒットした。

  1. DejaVu Sans Mono
  2. FreeMono
  3. Liberation Mono
  4. Nimbus Mono L

そこで実際にフォントを表示させてその視認性から判断した。表示結果を以下に示した。

Linux標準の英語フォントの比較

フォントを比較した考察は以下となる。

  • FreeMonoとNimbus Mono Lはフォントサイズが同じでもフォントが比較的細く小さく表示される。
  • アスタリスクの形がDejaVu Sans Monoだけ三本線で残りは星形。
  • DejaVu Sans Mono以外は数字の1と英小文字のlの違いが見分けにくい。

以下2点の理由から,DejaVu Sans Monoがベストだと判断した。

  • 数字の1と小文字のlとの識別のしやすさ。
  • アスタリスクの形がキーボード表示と同じ三本線。

まとめ

WindowsとLinuxの標準フォントからコーディングにおすすめするフォントは言語ごとに以下の表のとおりとなる。

おすすめコーディング用OS標準フォント
言語WindowsLinux
英語ConsolasDejaVu Sans Mono
日本語MS GothicTakaoGothic(Debian系),VL Gothic(RedHat系)

実際には,Windowsでは以下の問題点がある。

  • Consolasだと数字の1と英小文字のlとの判別が困難。
  • MS Gothicは文字がカクカクしていて見た目が汚い。

また,Linuxでは標準フォントの品質は高いが,共通で使える日本語フォントが存在しないという欠点がある。

上記の問題点はあるにしても,今回の調査はとても有用だったと個人的には思っている。例えば,以下の用途で活用可能だ。

  • CSSのコーディング用フォント指定。
  • テキストエディターのフォント設定。
  • ワープロでのコード表示部分のフォント設定。

実際に自分でも活用していこうと思う。

Set GVim default font

$
0
0

GVimでフォントを適切に設定する方法を記す。

導入

VimのGUIであるGVimでは,日本語フォントがきちんと設定されていないと日本語が横に間延びしたようになってしまいとても見にくくなってしまう。

これを防ぐには,GVimのフォント設定で日本語フォントをきちんと設定することが必要となる。しかし,存在しないフォントを指定するとWindows版のGVimでは以下のエラーが出てしまう。

E596: Invalid font(s)

なお,Linux版のGVimでは存在しないフォントを指定してもエラーは出ない。ただし,表示は横に間延びする。

一度きちんとフォント指定を済ませてしまえば,このような問題は起きないと思うかもしれないが,実はそうでもない。例えば,自分のPCではコーディング用にインストールしたフォントを表示するようにGVimで設定したとする。しかし,他人のPCでVimの設定だけ移動させて作業すると,フォントがインストールされていなくて,GVim起動時にエラーがでたり,表示が間延びしてしまう。

このようなフォント指定に対する問題を解決するには,設定したフォントが見つからなかった場合に,きちんと処理を入れれば済む。具体的には以下のどちらかとなる。

  • try-catch文で処理。
  • 処理の最後でOS標準フォントを指定。

try-catch文で対応する場合は以下のような設定を書けばよい。

try
if has("gui_running")
if has("gui_gtk2")
set guifont=Migu\ 1M\ 9
elseif has("gui_macvim")
set guifont=Menlo\ Regular:h14
elseif has("gui_win32")
set guifont=Migu_1M:h9
endif
endif
catch /^Vim\%((\a\+)\)\=:E596/ " catch error E596: Invalid font(s):
endtry

ただ,try-catch文で処理する場合だと,最初のフォントが見つからなかった場合にしか対応できない。最初のフォントが見つからなければ,次のフォントを試すといったことができない。そのため,最後にOS標準フォントを指定することを勧めたい。

既にWindowsとLinuxのOS標準のコーディング用フォントは以下の記事で調査済みなのでこの成果を活用すればよい。これを使えば,いちいちtry-catch文で複雑なことをしなくても済む。

おすすめコーディング用OS標準フォント
言語WindowsLinux
英語ConsolasDejaVu Sans Mono
日本語MS GothicTakaoGothic(Debian系),VL Gothic(RedHat系)

My Future Sight for Past: Best coding font in Windows and Linux default font

GVimのフォントのオプション

GVimでフォント設定に関するオプションは2種類ある。

それぞれ,英語(1バイト)と日本語(2バイト)フォントを指定する。guifontwideの値が空ならば,guifontの値が適用される。

WindowsとLinuxとでは,これらのオプションに指定する値の書式が少し異なっている。

Linuxであれば,フォント名の空白はバックスラッシュ\でエスケープする。フォントサイズは,フォント名の最後に空白に続けて指定する。

Windowsであれば,フォント名の空白にはバックスラッシュでエスケープする代わりにアンダーライン_も使える。フォントサイズ(高さ)はフォント名の直後にコロン:に続けて指定する。

また,これらのオプションには値をコンマ区切りで指定でき,先頭の値から順番に試し,最初に成功したものが値として適用される。例えば以下のようになる。

set guifont=Migu\ 1M\ 9, DejaVu\ Sans\ Mono\ 9  " Linux
set guifontwide=Migu_1M:h9,MS_Gothic:h9 " Windows

フォント設定例

コンマ区切りでフォントを指定できるので,上記で示したOS標準フォントを最後に指定すればそれで事足りる。しかし,そうはいかなかった。Windowsであれば,このコンマ区切りの指定は機能するのだが,Linuxでは機能しなかった。おそらくバグだと思う。この問題については,他にも以下で報告されていた。

VIM GTK-UI font - Stack Overflow

しかたないので,上記で書かれていたとおり,Linuxではフォントが存在するかどうかを判定して設定する。設定例は以下の通り。

" .gvimrc
let s:MYFONT = 'Migu 1M'
let s:MYFS = '9'
if has('gui_win32')
" ex: set guifont=Migu_1M:h9, Consolas:h9
let &guifont = s:MYFONT . ':h' . s:MYFS . ', Consolas:h' . s:MYFS
let &guifontwide = s:MYFONT . ':h' . s:MYFS . ', MS_Gothic:h' . s:MYFS
elseif has('gui_gtk2')
" set guifont=Migu\ 1M\ 9, DejaVu\ Sans\ Mono\ 9 " not working. Bug?
" set guifontwide=Migu\ 1M\ 9, TakaoGothic\ 9 , VL\ Gothic\ 9 " not working. Bug?
let &guifont = 'DejaVu Sans Mono ' . s:MYFS
if system('fc-list | grep -c ' . shellescape(s:MYFONT)) > 0
let &guifont = s:MYFONT . '' . s:MYFS
elseif system('fc-list | grep -c "TakaoGothic"' ) > 0
let &guifontwide = 'TakaoGothic ' . s:MYFS
elseif system('fc-list | grep -c "VL Gothic"' ) > 0
let &guifontwide = 'VL Gothic ' . s:MYFS
endif
endif

フォント内に空白があるとバックスラッシュでエスケープしないといけないことと,フォントサイズを一括で指定したいのもあったので,変数を使った。

最初のif has('gui_win32')でWindowsのフォント設定をしている。

elseif has('gui_gtk2')からLinuxでのフォント設定をしている。最初にLinuxで共通で存在している英語フォントであるDejaVu Sans Monoを指定しておき,後から自分で指定したフォントと日本語用フォントを追加で指定している。フォントの存在の有無の判定で使っている以下の文がこのスクリプトでは重要と思われる。

  if     system('fc-list | grep -c ' . shellescape(s:MYFONT)) > 0

Vimのsystem関数はShellで実行した標準出力を返す。fc-listコマンドはインストールされているフォントリストを表示するので,そこから対象となるフォントが存在するかをgrepで検索し-cオプションでヒット件数を返している。これによりフォントの有無を判定している。s:MYFONT変数内に空白があるので,shellescape関数でエスケープしておく。

これでGVimのフォントでの問題はなくなっただろう。

Solution for "mount: unknown filesystem type 'exfat'" on Ubuntu 16.04

$
0
0

64 GBのMicroSDをPCに接続したら,以下のメッセージが表示された。

Unable to access “64 GB Volume”

Error mounting /dev/sdb1 at /media/senooken/9C33-6BBD: Command-line `mount -t "exfat" -o "uhelper=udisks2,nodev,nosuid,uid=1000,gid=1000,iocharset=utf8,namecase=0,errors=remount-ro,umask=0077""/dev/sdb1""/media/senooken/9C33-6BBD"' exited with non-zero exit status 32: mount: unknown filesystem type 'exfat'

以下のサイトで書かれているコマンドを入力してexfatのパッケージをインストールしたら解決するらしい。

sudo apt install exfat-fuse exfat-utils

partitioning - How to enable exFAT in Ubuntu 14.04 - Ask Ubuntu

コマンド実行後アクセスできるようになった。解決してよかった。

Solution for "xterm: Cannot use 'bash' as shell: No such file or directory"

$
0
0

会社のPCでxinitコマンドを実行してGUIを起動すると以下のメッセージが端末に表示されていた。

xterm: Cannot use 'bash' as shell: No such file or directory

特に動作に問題はなかったので放置していたが,気になったので原因を調べた。

この現象はGNU screen起動後にxinitコマンドを実行したら起こっていた。そこで,GNU Screen起動中のSHELL環境変数を確認すると値がbashになっていた。おそらくこれが原因だろう。

現在screenコマンドは,~/.bashrcで以下のようにaliasを設定していた。

MYSHELL=$([ "$(command -v zsh)" ] && command -v zsh || command -v bash)
MYTERM=$([ -z "${TERM##*256*}" ] && echo screen-256color || echo screen)
alias screen="screen -T $MYTERM -s $MYSHELL"

ここでは-sオプションで,zshがあればGNU Screenの起動時のシェルをzsh,なければbashになるようにしていた。どうやら,この-sオプションで指定した値は,GNU Screen起動中の環境変数SHELLの値として設定されるようだ。この値には使用するシェルコマンドのフルパスを指定しないとだめなようだ。そこで,以下のように設定を変更した。

: ${MYSHELL:=$(command -v zsh )}
: ${MYSHELL:=$(command -v bash)}

MYTERM=$([ -z "${TERM##*256*}" ] && echo screen-256color || echo screen)
alias screen="screen -T $MYTERM -s $MYSHELL"

MYSHELL変数が設定されていなければ,command -vコマンドの実行結果を設定するようにした。command -vコマンドでは引数に指定したコマンドが存在すれば,そのフルパスを返し,なければ何も返さないコマンドだ。

これで解決した。エラーが消えてすっきりしてよかった。

#LinuxCon Japan 2016参加レポート

$
0
0

LinuxCon Japan 2016に参加したので参加レポートを記す。

最初にイベントの概要と全体の感想を記し,最後に参加した個別のセッションの感想とメモを記す。長いです。

目次

  1. 参加のきっかけ
  2. イベント概要
  3. 全体の感想
    1. コンテナー技術
    2. オープンコンプライアンス
    3. カーネルドキュメント
    4. CI/CD(ContinuousIntegration/Development)
    5. その他のセッション
    6. 食事
    7. まとめ
  4. 1日目
    1. Keynote: Open Source Landscape
    2. Keynote: Overview of Hyperledger
    3. Keynote: Embedded Linux in lndustry and Civil lnfrastracture Systems
    4. Keynote: The Rise of the Open Source Program Office
    5. Keynote: The Kernel Report
    6. Keynote: Fujitsu with Open Source Communities
    7. Linux Kernel Security Update
    8. Fail Fast, Fail Often
    9. Introducing the Civil lnfrastructure Platfom Project
    10. Networking Containers in an Ultra-Low Latency Environment
  5. 2日目
    1. Keynote: Cloud Native and Container Technology
    2. Keynote: Back from the Future: Open Source Compliance
    3. Keynote:Conversation with Linux Creator
    4. Kernel Documentation: What We Have and How We'll Make it Better
    5. Continuous Integration and Delivery for Free and Open Source Software
    6. A Gentle lntroduction to Linux Containers
    7. Container Standardization lntroduction
    8. Solving Device tree lssues, Part2.0
    9. Showing Management the Light: Explaining the Business Strategy Behind Investing in Community Best Practices
  6. 3日目
    1. Tracking Huge Files with Git LFS
    2. Introduction to the Fuego Test Framework
    3. Fluentd and Coutainers
    4. Why Fujitsu Joined the CNCF
    5. Live Patching for Linux
    6. (In)security in Open Source
    7. Keynote Panel: Open Source Evolution for Carries
    8. Keynote:Kernel Developer Panel

参加のきっかけ

LinuxConの存在は2014年の夏ごろに知った。ちょうどLinuxCon Japan 2014の開催直前だ。何でもLinuxの創生者のLinusも参加するらしい。自由ソフトを信じてLinuxの利用者として,一生に一度は参加すべきだろうと思っていた。初めに知ったときはタイミングが悪くて参加できなかった。また,その次の年の2015年も仕事の都合がつかず参加できなかった。今年は都合がついたので参加した。

平日開催なので,有休をとるか研修として参加するかのどちらかとなる。幸運なことに,会社で許可をもらえたので有休を使わずに外出扱いで参加できた(参加費は自己負担)。

この参加レポートは会社に提出した参加報告書をベースにして,URLなど追記したものになっている。

参加中に思ったことなどはツイートして,以下でまとめた。

LinuxCon Japan 2016参加中の自分のツイートまとめ - Togetterまとめ

イベント概要

イベントの基本情報を以下の表にまとめた。

LinuxCon Japan 2016開催概要
項目内容
イベント名LinuxCon+ContainerConJapan2016
主催団体TheLinuxFOundation
URLhttp://events.linuxfoundation.org/events/linuxcon-japan/
資料http://events.linuxfoundation.org/events/linuxcon-japan/program/slides
開催地椿山荘
参加日2016-07-13水~2016-07-15金

LinuxCon Japanは毎年1回開催される東アジア最大のLinuxに関する国際カンファレンスとなっている。Linux Kemelのコア開発者やLinuxの創生者のLinus Torvaldsも参加する。 LinuxConと併設して、コンテナー技術に特化したContainerConと自動車技術に特化したAutomotive Linux Summitも同時開催された。Automotive Linux Summitは有料だが、LinuxCon参加肴はContainerConにも無料で参加できる。また、セッションには別料金の発生するチュートリアルセッションがあり、IoTに関する技術のハンズオンなど
も開催されていた。

LinuxConとContainerConのセッションを合計して、3日にかけて約100のセッションが開催された。LinuxCon自体の参加料金は早割適用により350~450 USDの金額となっている。今回は早割を適用し350USD(約4万円)を自費負担して参加した。

3日間のイベントで共通して、以下のスケジュールとなっていた。

  • 8時から受付と朝食。
  • 09:00~17:30までセッション。

当日の発表資料の一部は以下のページで公開されている。 3年ほどしたら見られなくなってしまうので、必要な資料はダウンロードしたほうがいい。

http://events.linuxfoundation.org/events/linuxcon-japan/program/slides

全体の感想

国際カンファレンスということで、外人が多く、発表は英諾であり新鮮だった。知職不足なのもあり、内容の理解が不十分なこともあったがいくつか新しい知見が得られてたいへん参考になった。

カンファレンス全体でとくに興味を持ったのは以下の4項目だ。

  1. コンテナー技術
  2. オープンコンプライアンス
  3. カーネルドキュメント
  4. CI/CD

コンテナー技術

このテーマは以下のセッションが該当する。

コンテナー技術は2013にリリースされたオープンソースソフトウェア(OSS)であるDockerの登場頃から急成長をとげ、言葉だけよくきいていた。事前に調べて仮想化の技術(コンテナー仮想化)ということは理解したが、従来のVirtualBoxやVMwareなどによるVM仮想化との違いがいまいちわかっていなかった。今回のカンファレンスでその遠いと利点がよくわかった。

コンテナー技術は昔からあるが、最近になって急成長を遂げたのはクラウドやマイクロサービスと相性がよく、VM仮想化と比べ、クライアントOSが不要なためパフォーマンスがよく、効率がとてもよいからとわかった。

クラウド事業を行っていなければ、VM仮想化でも十分そうだが、テスト環境やサーバーを立てるときなどにも使えるので、選択肢の一つとして知っておいた方がいいと思った

オープンコンプライアンス

近年になって、 Bash、OpenSSI,など有名なOSSにセキュリティ問題が発覚してきた。今までオープンソースは技術的に普及しており、安全な印象を持っていた。今回のカンファレンスでは、OSSのコンプライアンスやセキュリティ脆弱性に関するセッションがあり、初めて知ることが多くとても興味深かった。具体的には2日目と3日目の以下のセッションが該当する。

    社内においてもOSSはふんだんに活用している。インターネットにつながっていないので脆弱性は大きな問題にはならないと思うが、コンブライアンスの考え方や管理方法は開発ソフトの品質を向上させるためにも有用だろうと思った。

    このオープンコンプライアンスについては以下がキーワードとなる。

    • OpenChain:標準化の仕組み
    • SPDX:メタデータの形式
    • FOSSBazzar:管理ソフト
    • Core Infrastructure Initiative:団体

    時間を見つけて調べて、知見を深めていきたい。

    カーネルドキュメント

    このテーマは2日目の[Kernel Documentation: What We Have and How We'll Make it Better]の内容だ。

    個人的な興味として、ドキュメンテーションをどうやるかに関心があった。複数人での共同開発、ましてやLinuxカーネルのような巨大なプロジェクトにおいてはまとまった文書の存在がきわめて重要になってくる。ただ、文書のメンテナンスの労力は無視できないので、いかに効率よく文書化システムを整えるかが重要だろうと思っていた。

    Linuxカーネルとしては、もともとは独自ツールとDocBookをベースにやっていたが、いまいちだったので、MarkdownやAsciiDocを試して今はSphinxに落ち着いたとのことだ。 Sphinxの存在は知っていたが、個人的には汎川性からAsciiDocを好んでいた。

    今回、 LinuxカーネルでSphinxが使われているのを知り、改めて調べたところ、 SphinxではC言語のAPIを記述するための記法(Doxygenの関数の説明記法に似たもの)が標準で用意されていた。AsciiDocでもおそらく拡摂機能を作れば実現できると思われるが、標準でこういう機能があるのはとても重要で、ソースコードの文書化ツールに特化したSphinxならではの芸当だと思った。

    CI/CD(ContinuousIntegration/Development)

    開発効率を上げるには、 自動化というのが大きなポイントとなってくる。

    巨大なプロジェクトになってくると、なおさら重要になる。ピルドやテストなど少しでも自動化できるところはできるだけ自動化を図つた方がいいだろう。

    このためのツールとして、 2日目の[Continuous Integration and Delivery for Free and Open Source Software]で紹介されていた以下のようなツールは調査検討しておいたほうがいいと思った。

    • Git
    • Gemt
    • Zuul
    • Jenkins
    • Nodepool

    その他のセッション

    1日目の[Networking Containers in an Ultra-I,ow-Latency Envimnmentlの発表では、ネットワークの応答速度の実験をしており、この結果は有用な部分があるのではないかと思った。

    また、3日目最後のLinuxカーネル開発者のパネルディスカッション[Keynole: KemeI Developer Panel]で、静的解枅ツールとしてcoccinelleSmatchがおすすめされていたのが気になった。

    Smatchはあまり情報がなく,coccinelleのほうが情報が多そうだ。coccinelleについては,これを扱った発表があったようだ。

    INTRODUCTION TOCOCCINELLE AND SMPL

    また,カンファレンス終了後に公開されたスライドで興味深かったのが,Googleのオープンソースへの貢献に関する発表。

    How Google Uses and Contributes to Open Source

    Googleは標準のライセンスとしてApache2を採用している。特許を明示的にできるのがいいらしい。一番気になったのは,CC0について。CC0ライセンスのコードは,貢献しても自分たちの著作権を保持できないので,使ったり貢献できないとか。会社でやる以上,著作権の保持はしたいということのようだ。

    食事

    高級ホテルでの開催ということと国際カンファレンスということで食事がよかった。お昼ごはんはカンファレンス参加申し込み時に,事前に選ぶことがで き,菜食主義者,ヴィーガン,グルテンフリーに配慮していた。今回は菜食主義者で申し込んだので,お昼ごはんは菜食弁当だった。このお弁当がとてもおいしかった。雑穀をメインとした料理となっていて,サラダなどに使われているオイルがとてもよかった。未来食カフェレストランTUBUTUBというお店で作られたお弁当だった。

    以下にお昼弁当の写真を掲載しておく。

    お昼ごはんの他に,朝食にパンと3時のおやつにクッキーも配られていた。

    クッキーは大量に配られていて,20枚くらい食べても有り余るほどあって驚いた。

    また,最終日の3日目の最後のセッションの終了後は,レセプションとしてパスタなどの軽食とお酒も振る舞われていた。食事は量があまりなかったので,不足気味だった。

    食事とは関係ないが,基調講演のような広い会場では,冷房が強くかかっていたので,長袖の上着を用意していたほうがよかった。半袖だと寒くて内容にあまり集中できないのでもったいなかった。

    まとめ

    Linux創生者であるI,inus Torvaldsと直接あって会話ができて,一緒に写真に写ってもらえたのがとてもよい思い出となった。

    参加費が約4-5万円ということと,開催日が平日なので参加するのは難しい。3-5年に1回最新技術の動向を追うという意味で参加するくらいがちょうどいいだろうと思った。

    発表内容としては,必ずしもLinuxに直接関わるものでなくてもよいので,次回参加するときは発表者として参加できたらいいなと思う。

    次の節からは開催日ごとのセッションのメモを記していく。

    1日目

    Keynote: Open Source Landscape

    Jime Zemlin

    オープンソースへの投資の状況、マーケット、市場変化について説明。現在ではすべてのコードでオープンソースが支配的であり、オープンソースに自社コードをプラスすることで、企業は価値を創出している。

    一方で、オープンソースは複雑さやリスクも抱えているので、それを管理していくことも必要である。

    こうしたオープンソースを支えている団体としてLinux Foundationを紹介し、スケール可能なオープンソースの要件として以下の要素をあげた。

    • 統制とメンバーシップ
    • 開発プロセス
    • インフラ
    • IP

    さらに、オープンソースプロジェクトに横断して必要な要件を示した。

    • セキュリティ
    • ガバナンスとエコシステム
    • ライセンスと1P
    • 教育と認証

    オープンソースは少ない投資で多くが得られる分野であるので、参加する利点が大きい。

    Keynote: Overview of Hyperledger

    Brian Behlendorf

    初めて知ったHyperledgerというデータベースのブロックチェーン技術を発展させたオープンソースプロジェクトの紹介。既存のデータベース技術の問題点を指摘し、Hpyerledgerがそれらを解決することを目標にしている。

    伝統的データベース処理では、遅延が問題なってきた。分散型データベースにおける、ブロックチェーンには以下の問題がある。

    • スループットの制限
    • 遅い処理・確認
    • プライバシーがない
    • 匿糸性

    Hyperledgerはブロックチェーン技術を発展させ、複数の産業標準を考慮でき、ビジネス取り引きを確実にできる。

    Keynote: Embedded Linux in lndustry and Civil lnfrastracture Systems

    JanKiszka(Siemense),WshitakeKobayashi('Ibshiba),HimshiMine(Hitach)

    産業や雑盤インフラにおけるLinuxの砿要さを打ち出した発表だった。ビジネスカンファレンスでよくある事例紹介で個人的にはあまりおもしろくなかった。

    Keynote: The Rise of the Open Source Program Office

    Gil Yehuda(Yahoo)

    オープンソースを組織で適用していく際の戦略についての話だった。かなりビジネス寄りの話が展開され理解が難しい内容だった。

    Keynote: The Kernel Report

    JonathanCorbet(LWN.net)

    LinuxKemelの開発状況についての発表。

    LinuxKemelは現在だいた70日くらいでバージョンを上げている。次のリリースが7/17の4.7の予定。

    ここ数年の傾向として、 リリースごとの貢献者数は微増。開発コミュニティの変化はほとんどなく、継続がスムーズになった。

    そのほか、Linux Kemelの課題として以下の項目について言及した。

    • セキュリティ
    • メモリー
    • カーネルバイパス
    • 転送プロトコル
    • ライセンス
    • 文書

    Keynote: Fujitsu with Open Source Communities

    KeniiKaneShige(Fujitsu)

    富士通がLinux Kemelやオープンソースコミュニティになぜ参加するか、どういう貢献をしているかについて説明していた。

    富士通はここ 10年くらいオープンソースにコミットしてきた。従来はLinuxOSへのコミットが多かったが、ここ2-3年でOpenStackへのコミットが急増して、全体の半分がOpenStackへのコミットとなった。

    富士通がOSSに参加する理由について説明。一般的に、開発コストを減らすにはどうすればいいか考えたとき、単一の会社で行うとコストが高くつく。しかし、コミュニティで協力するとコストは高くない。また、信頼できるプラットフォームを自社が提供するうえで、使用しているオープンソースの改善が必要だった。

    オープンソースへコミットすることで社内のエンジニアの成長にもつながった。

    Linux Kernel Security Update

    JamesMoITis(Oracle)

    資料:http://events.linuxfoundation.org/sites/events/files/slides/linux_kernel_security_linuxconjp2016.pdf

    Linux KerneIのセキュリティサブシステムのコア開発者による現在の状況の報告。Linux Kernelの機能について細かい説明が多く理解が難しかった。

    Fail Fast, Fail Often

    GordonHafT & WilliamHenly(RedHat)

    開発において、失敗はつきもの。この話では上手な失敗の仕方についての発表だった。

    上手に失敗するうえでは5の規範を守ることが亜要となる。

    1. 適切な範囲:失敗の影響を制限。
    2. Small :十分に定義された機能に分割。
    3. AUTDNOMOUS:実装の変化をほかのサービスから独立させる。
    4. 適切なアプローチ:継続的な実験と反復。
    5. Pmcess:関係者を巻き込んでコミュニケーションをとる。

    そして、繰り返しの自動化。ビルドと組織のシステム化は上手な失敗を容易にする。

    Introducing the Civil lnfrastructure Platfom Project

    Yoshitake Kobayashi(Tbshiba, JanKisZka(Siemens)

    資料:http://events.linuxfoundation.org/sites/events/files/slides/Intriducing_the_CIP-LCJ2016.pdf

    インフラとして使われるようなオープンソースやLinuxカーネルの保守の話。

    オープンソースは般化した技術を使っているので、安全な面がある。逆に、コードをクローズドにしてしまうと近い将来で深刻な問題を引き起こす。他のソフトのアップデートで不確合が起きて問題になる。

    Linuxカーネルは3か月ごとに更新しており、 ITS(Long Term Support:長期サポート) として2年サポートしている。しかし、一般的にインフラでは少なくても10年はサポートが必要。そこで、CIPというプロジェクトがあり、これでLinux Kemelを10年サポートしている。

    あるソフトを10年ごとに更新するのは変化が多くたいへん。だからといって、2年おきに更新すると10年で5回更新することになる。小さなパッケージから始め互換性を保つことが重要となる。

    Networking Containers in an Ultra-Low Latency Environment

    AviDeitcher(AtomicInc.)

    GoogleやAmazonなどは通信速度が少しでも遅くなればそれがダイレクトに損失につながってくる。

    Latency(通信の要求開始から応答までの速度)がとても短いネットワーク (ULL)を行うのにどういうハードを使えばいいかの実験の報告。

    結論

    • SR-IOVは試す価値がない。
    • Metalは常に最高のパフォーマンス。
    • Direct network++ではmacvlanは頼もしい。
    • ULI, :Metal/net = host > macvlan > callco > overlay

    最終的には自分のアーキテクチャーとスキルに焦点を当てる必要がある。

    ネットワークについて知識はあまりないが,とても有用な発表だったように思えた。

    2日目

    Keynote: Cloud Native and Container Technology

    ChrisAniszDWk(TheLinuxFoundatiOn/CNCF)

    クラウド業界やコンテナー技術の動向についての発表。最近コンテナー技術と呼ばれるものが流行ってきており、なぜ流行ってきているのか興味深かった。

    最近の傾向として、世界の大企業はどんどんソフトウェアの会社になろうとしている。例えば、自動車会社や旅行会社。TOYOTAはスタンフォードの博士と協力してAIを研究している。

    また、データの収集・利用が以前にもまして重要さを上げてきている。

    例えば、Web会社

    • Google
    • Twitter
    • Facebook

    これらの会社でのソフト開発はサービスを売るためにやっている。

    大企業で使われるクラウドコンピューティングの特徴として以下の要素がある。

    • コンテナー技術
    • マイクロデバイス

    クラウドにおいて、コンテナー技術を使うと非常に効率がいい。人件費を大幅に削減でき、ダイナミックなスケジューリングが可能。

    これがGoogleやTOYOTAでコンテナー技術が使われる理由。

    例えば、コンテナーの利用スケールは以下となっており、かなり使っている.

    • Google:20億
    • Facebook:30万
    • Twitter:25万
    • Netfix: 1万

    こうした企業では過去にスケールで失敗しており、研究してたくさんのソフトを試してきた。

    こうした動きを受け、昨年2015年にクラウドコンピューティングの団体ができた。CIoud Nalive Compuling Foundation (CNCF)。最後にこの団体でどういうことをやろうとしているのかを報告。

    Keynote: Back from the Future: Open Source Compliance

    DavidMarr(Oualcomm)

    法律家によるオープンソースコンプライアンスの話。この話ではOpenChainとSPDXというキーワードが印象的だった。

    オープンソースのコピーレフトという考え方は、とてもクリエイティプで法律家としても好きな考え方だった。しかし、オープンソースの中には間違っているものもある。 間違っていてもそのまま情報が受け継がれていく.自己修正のメカニズムがない。これはリスクが大きい。バグフィックスのライセンスがない。

    これを解決するために、OpenChainというアセスメントの標準がある。これに従うことで、効率性や透明性を上げることができ、オープンソースのリファレンスモデルとなる。さらに、SPDXというメタデータの文書形式がある。これに現在のコードの問題点などのメタデータを組み込むことで、 自己修正がしやすくなる。OpenChainとSPDXをもっと広めていきたい。

    Keynote:Conversation with Linux Creator

    DarkHohndel(VMwarc),Linux.Torrvalds

    Linuxの創成者であるI,inus TbrvaldsとVMwareの人による対淡。Linuxのカーネルの話はよくわからなかった。気になった点を抜粋。

    • カーネルの2ノ3はドライバー。残りがアーキテクチャーやファイルシステム。
    • 優れたメンテナーはよいテイスト (趣味)がある。プログラミングとは述う。プログラミングはエンジニアリングで、みかけや動作がいいことを要求される。例えば、美しくて機能のある家。これを気にしているのではない。同じことを見ても、もっといい方法があるだろうと思えること。これだったらいいぞと理解できる人がいい.

    Kernel Documentation: What We Have and How We'll Make it Better

    Jon Corbet(LWN.nel)

    Linux Kemelにおける文書化の話。個人的にはかなり興味のあるテーマだった。

    カーネルツリー全体の俯瞰は必要だが、もともと相互参照やほかの文書を参照するようなものはなかった。文書はカーネル開発に参加するときのとっかかりの最初となることが多い。

    Linuxカーネルの開発は25年の歴史があるが、最初の15年間は文書がいまいちだった。

    規模感

    • カーネルのソースコード:53654ファイル
    • カーネル文書
      • 2264ファイル
      • 228ディレクトリ
      • 23MB

    カーネル文書の形式は以下の3形態がある。

    • .txtファイル(2000+)
    • DocBook形式(34のテンプレート) (重要事項の文書)
    • Doxygenに似たKernelコメント (55000個)

    文書化には従来、開発者が自作した文書システムを使っていた。ただ欠点がある。

    • 遅い
    • britlIe
    • 設定とmakeが難しい。
    • 汚い
    • 残りの文書との統合ができない。

    ここ最近kerneldocにmarkdown処理を加えた。その後asciidocに切り替えた。

    これにより,

    • DocBookを回避
    • よりよい文苫

    欠点

    • 新しいツールの追加
    • ツール間での不整合
    • パフォーマンス
    • 文書間でのリンクがない。
    • Ruby依存

    カーネルの文書化でやりたいこと。

    • DocBookはやめたい。
    • 簡単なマークアップを使いたい(MaIkdown、AsciiDoc,Sphinx)
    • 書式化していない.txt文書にもそのまま適用したい。

    これらを実現するために文書化ツールを再検討とした。それでSphinxに目を付けた。

    Sphinxの利点

    • コードの文書化に特化
    • でかい文書にも対応
    • 世界的に使われている
    • 出力はHTML、EPUB、PDF
    • DocBookやTeXに頼らない

    一部簡単な拡張機能を作って使い始めた。今後はSphinxの適用を拡大予定。

    Continuous Integration and Delivery for Free and Open Source Software

    DongMa(HPE)

    資料:http://events.linuxfoundation.org/sites/events/files/slides/Continuous%20Integration%20and%20Delivery%20for%20Free%20and%20Open%20Source%20Software%20Development_0.pdf

    OSS(OPenStack)におけるCI/CDの重要さとその流れについての発表だった。

    巨大なオープンソースプロジェクトでは、CI/CDもスケールしないといけない。OpenStackでは以ドのツールを組み合わせてCI/CDを維持している。

    • Git
    • Gerrit
    • ZuuI
    • Jenkins
    • NodepOol

    A Gentle lntroduction to Linux Containers

    BrianPmmt(RedHat)

    資料:http://events.linuxfoundation.org/sites/events/files/slides/gentle-intro-containers-LCJapan2016.pdf

    Linuxのコンテナー技術全般の紹介とDockerの使い方に関する発表。この発表でコンテナー技術の特徴がよくわかった。

    Linuxコンテナーの特徴は以下となっている。

    • ユーザースペースだけ。ホストカーネル上でイメージがアプリを実行。
    • アプリ+ランタイムの依存関係を持つ。
    • ホストと同じOSであること。
    • アプリはホストOSから独立。

    コンテナー技術と仮想化技術は似ている。VMに対するコンテナーの特徴は以下となる。

    • コンテナーの方が軽い。コンテナーの方が小さく、必要なリソースが小さい。
    • 同じOSに制限される。
    • コンテナーはマイクロサービスのためにある。

    コンテナー技術自体は新しいものではなく、歴史としては1998年のchroootに始まる。

    Linuxコンテナーの利点は以下となる

    • 環境をまたぐ商いポータピリティ性。
    • 開発とテストの一箇性.
    • VMに比べ動作が早く容量が小さい。
    • 他人の作業の上で使える。
    • モジュール化。
    • レガシー環境の扱いがとても簡単。

    Container Standardization lntroduction

    MaShimiao(Fujitsu)

    資料:http://events.linuxfoundation.org/sites/events/files/slides/container_standardization_introduction_v3.pdf

    最近急成長してきたコンテナー技術の標準化に関する話。

    仮想化を、コンテナー技術を使ったコンテナー仮想化とVMを使ったシステム仮想化の二つに分頽。

    コンテナー仮想化がシステム仮想化に比べて軽い理由は、システム仮想化はHOST上にゲストOSをそれぞれ持つのに対し、コンテナー仮想化はホストOSだけでいいから。

    コンテナー技術が最近急成長してきた理山は以ド3点。

    • ポータピリティ
    • ユーザービリティ
    • Agility

    コンテナー技術の急成長に伴い、多くのコンテナー技術ソリューションが'生まれた。

    • Docker
    • Rocket/rkt
    • OpenVZ/Odin
    • Hpyer

    しかし、これらは互換性がなく、業界標準がない。どのアプリがベストなのかユーザーは遡択が難しい。

    そこで、OCI (Open Container lnitialive) という標準化団体が2015-06-22に設立された。

    Solving Device tree lssues, Part2.0

    FrankROwand(SOny)

    l.inuxのデバイスツリーについて、デバッグ方法の紹介。設定ファイルの説明など細かい情報が多く、 デバイスツリーについて知識がなかったのでよくわからなかった。

    Showing Management the Light: Explaining the Business Strategy Behind Investing in Community Best Practices

    ShadeCoUgh!an(Insignary)

    オープンソースコンプライァンスの話。

    オープンソースは78%の会社で使われており、オープンソースによりイノベーション速庇が速くなった。

    プロプライエタリなソフトと同様に、オープンソースにもセキュリティ検査や監視が必要.67%の会社がOSSの脆弱性を監視しきれていない。

    オープンソースというのはコードだけでない。法律やビジネス戦略もかかわってくる。

    OpenChainは、オープンソースのサプライチェーンの作るために必要な仕組み。

    コンブライアンスのためのツールとしては以下がある。

    • Binary analysis
    • FOSSOLOGY

    オープンソースの知識はほかのステークホルダーから利用可能。コミュニティの全員はオープンソースの継続的成長に興味がある。自社の成功にもつながる。

    フリーライダーは市場からフェードアウトしていく。

    3日目

    Tracking Huge Files with Git LFS

    TimPcttcrscn(Allassian)

    資料:http://events.linuxfoundation.org/sites/events/files/slides/Tracking%20huge%20files%20with%20Git%20LFS%20-%20LinuxCon%20JP.pdf

    Gitで巨大なバイナリーファイルを管理するGit I,FSの発表。Gitの仕組みの説明もあり勉強になった。

    なぜGilは巨大ファイルの管理が苦手か。これを知るにはGitの仕組みの理解が必要。

    Gitではコミットごとにオブジェクトへの参照(ポインター)を持っている。親のコミットから親のディレクトリへ、そこからさらに個別のファイルへの参照を持っている。これにより、変更があったファイルだけの差分を持つことができている。

    しかし、バイナリーファイルは少しでも差分があればカウントしてしまう。だから、 単一で50MBのファイルでも2回目の変更で+50MBで合計100MBとなってしまい、どんどんリポジトリが肥大化.

    これを防ぐために、Git LFSではさらにもう一つポインターを間に持つ。これにより、ホストとLFSとで保存先をわけることできる。 git pullしたときには最新のI,FSだけを提供することで、 リポジトリの肥大化を抑制する。

    Introduction to the Fuego Test Framework

    Tim Bird

    資料:http://events.linuxfoundation.org/sites/events/files/slides/Introduction-to-Fuego-LCJ-2016.pdf

    テストフレームワークのFucgoの紹介。コンテナー技術の応用としてなるほどと思って。環境を統一するのにもコンテナーは有用だと思った。

    Fuego=(Jenkins + abstraction Scripts + pre-packaged test) inside a container

    フロントエンド:Jenkins

    バックエンド:シェルスクリプト

    Fluentd and Coutainers

    Satoshi Tagomori & Masahiro Nakagawa(Tresure Dala)

    ネットでよく見かけるが実態をよくしらないFluentdというログの収集分析ソフトの話。

    まず、最初に伝統的なロギング方法の問題点を指摘し、 Fluentdの特徴を説明。最後にFIuentdとコンテナーの組み合わせを紹介していた。

    伝統的なロギングにはryncが使われていた。これには以ドの問題がある。

    • ログたまり、収集が終わるまで1日またないとけない。
    • データ形式がぱらぱらで解析が困難

    FIuentdの特徴

    • Low Latency
    • ログをJSON形式に整形。

    Apache、Hadoop、MySOl.、 AWSなど変換が簡単。

    データ構造にQueを使っており、チャンクごとにデータをため込んでいる。これにより、転送途中で送信が失敗してもリトライが少なくて済む。

    コンテナーだと、大量に一つのところにログが転送される。これだと負荷が大きすぎる。サーバー側にFIuentdを常駐させ、さらに間にアグリゲーションサーバーを一つはさむことで、 うまくいく。

    Why Fujitsu Joined the CNCF

    Hiroyuki Kamemwa & Wolfgang Ries(Fujitsu)

    富士通がCNCF(Cloud Native Computing Foundation)に参加した敬意とその活動についての発表。

    CNCFはコンテナーパッケージやマイクロサービスを念頭においた団体。 10000の新しいパラダイムが生まれた。

    データを集めてそのあとどうするか?データを活用して高い生産性につなげよう。

    クラウドプラットフォームは極めて生産性が高い。今プラットフォームの在り方が変わってきて、オンデマンドプラットフォームになってきた。 コンテナーを使えばオンデマンドプラットフォームの実現が簡単になる。

    富士通がOSSに入ったのは、 白分たちが治すす必要のある問題があったため。

    Live Patching for Linux

    Vojtech pavlik(SUSE)

    プログラムの動作中にパッチによる修正を施すLive Patchingの事例と実演。内容が少し難しくてあまり理解できなかった。

    膨大なコスト (100kUSD/hour)の削減のためにLive Patchingが必愛な場面がある。

    • 問題発生時:動作停止
    • 緊急対応:脆弱性対応

    Live Patchingは一般的にはDSU(Dynamic Software Updates) と呼ばれる。

    関数を新しく作って差し替えたり、オブジェクトファイルだけを差し替えたり、いくつか方法がある。

    (In)security in Open Source

    Shane Coughlan(Insignary)

    オープンソースのセキュリティ問題とその関連ツールについて言及。

    オープンソースで起きた有名な脆弱性。

    • Hertbleed
    • Shellshock(bash)
    • Freak
    • Ghost
    • Venom

    他にもDROWN攻撃で11百万のサイトがOpenSSLを使いリスクを冒していた。韓国ではIotでバスの到着情報がハックされた。

    どうすればいいか。十分なレビューがされていないからではないか。文書化が必愛なもの、自動化できるものを決める。FOSS BazzarとかSPDXでこうしたコンブライアンスに関する情報を管理できるようにする。

    Keynote Panel: Open Source Evolution for Carries

    Ashiq Khan(Docomo Research Labs), Masashi Kudo(NEC), DanieI Farrell (Red Hat), Marc Cohn(The l,inux Foundation)

    ネットワークのキャリアなど業界のトップによるオープンソース革命についてのパネルディスカッション。ビジネスよりな話が多く内容は難しかった。主にオープンな組織運営とその利点に関する話が多い印象だった。

    Q. 組織においてオープン性の実現に必要なことは何か?

    A. 歴史的には小さな会社と人きな会社があると、最初は大きな会社が支配的になる。時間がたって多くの頁献荷が入ってくると、最初にいたコミッターの役割が変化して中立性が生まれてくる。多様性を維持することがオープン性とII'立性に必要な要素の一つといえる。

    Q. オープンとクローズドでそれぞれどういう利点があるか?

    A. クローズドにするときは、 IPとか売り上げを独占したいとき。オープンを選んだらIPはすべてリリースしないといけない。隠せない。ただ、皆の意見が社外コミュニティに実装されてうれしいことがある。技術戦略としてはクローズドよりはオープンの利点が大きい。

    Keynote:Kernel Developer Panel

    GregKman-Hartman,LaurengPincharLChristophHellwig・JamesMomsMasamiHimmatsu

    Linuxカーネルのコア開発者によるパネルディスカッション。話が早くてメモが間に合わなかった。

    Q.プロジェクトで使う言語を変えることがあるか?

    A. その言語が30年使えるか、統合できるか。静的な型チェックができることはかなり重要。もう一つはコンパイラー。このあたりを満たせれば検討の余地はある。

    O. 最初のカーネルのパッチをどうやって出せばいいか?

    A. どういう手順でどういうパッチをどこにだせばいいか、文書化しているのでそれに従えばいい。

    Q. パッチをリジェクトされたらどうすればいいか。せめて理由を教えてほしい。

    A. 粘り強くやってほしい。メンテナーも忙しいときがある。できるだけ返信しようとはしている。宛先にメンテナー、CCにMLを入れてメールを出してくれると誰かに読んでもらえる可能性が高い。CCにメンテナーを入れてもフィルターで弾くことがある。

    O. SF的な質問だが、巨大な帝国は滅びることが世の常だが、 Linuxは残るだろうか?

    A. AIにメンテさせるとか、それこそターミネーターの世界。 Linuxはレガシーコードベースのものが多いので、なくならないと思う。なくなるとしたら、オーバーヘッドが無視できないとか、新しい技術などが入ってきて共同できなくなったときだろうか。

    Q. Linuxのいいところはどんなところか?

    A. 進化の形がいい。ライセンスがGPLだから、どんな変化もForkもマージできる。そして、大企業の影響を受けないのが強い。OpenStackは企業ベースだから辛いだろうね。

    O. 静的な型チェックツールで何かおすすめはあるか?

    A. coccinelleとSmatchがよい。 とくにcoccinellは3年前にしっていれば採用していた。


    Install Subversion 1.9.4 from source on Ubuntu 16.04

    $
    0
    0

    バージョン管理ソフトであるSubversionをソースからインストールする。

    会社で採用されているVCS(Version Control System)がSubversionだった。普段はWindows PCからTortoiseSVNというGUIから操作しているが,コマンドラインからも操作できたほうがいいと思ったので,ソースからインストールしてみた。

    インストール手順は,ダウンロードページの一番下の[Building and Installing Subversion]示されているインストール手順のページで書かれている通り,Subversionのソースに含まれるINSTALLファイルを参照する。

    Subversionで最低限必要な依存関係は以下のとおりとなっている。

    • autoconf 2.59+
    • libtool 1.4+
    • C compiler (gcc)
    • libapr, libapr-util
    • SQLite
    • libz

    上記の内の大部分はOSに標準でインストールされている。例えば,locateコマンドでインストールされているかどうかがわかる。locateコマンドでライブラリを指定して何も表示されなければインストールされていない。

    locate libapr

    今回は,不足していたlibapr,libapr-util,SQLite,libzをソースからインストールした。

    インストールはUbuntu 16.04とFedora 19で確認した。

    libz

    libzは圧縮のためのライブラリである。

    Source: zlib Home Site

    style="font-family: Inconsolata,"Migu 1M",monospace;">LOCAL=~/.local
    PKG=zlib
    VER=1.2.8

    cd $LOCAL/src
    wget -nc http://zlib.net/$PKG-$VER.tar.xz
    tar xf $PKG-$VER.tar.xz
    cd $PKG-$VER
    ./configure --prefix=$LOCAL/stow/$PKG-$VER
    make && make install
    cd $LOCAL/stow; stow $PKG-$VER

    libapr, libapr-util

    libaprとlibapr-utilをインストールする。これらはApacheで開発されているソフトで共通で使われるライブラリらしい。

    libapr-utilにはlibaprが必要なので,先にlibaprをインストールする。

    Source: Download - The Apache Portable Runtime Project

    LOCAL=~/.local

    PKG=apr
    VER=1.5.2
    cd $LOCAL/src
    wget -nc http://www-eu.apache.org/dist//apr/$PKG-$VER.tar.bz2
    tar xf $PKG-$VER.tar.bz2
    cd $PKG-$VER
    ./configure --prefix=$LOCAL/stow/$PKG-$VER
    make && make install
    cd $LOCAL/stow; stow $PKG-$VER
    PKG=apr-util
    VER=1.5.4
    cd $LOCAL/src
    wget -nc http://www-eu.apache.org/dist//apr/$PKG-$VER.tar.bz2
    tar xf $PKG-$VER.tar.bz2
    cd $PKG-$VER
    ./configure --prefix=$LOCAL/stow/$PKG-$VER --with-apr=$LOCAL
    make && make install
    cd $LOCAL/stow; stow $PKG-$VER

    SQLite

    最後の依存関係として,DBソフトであるSQLiteをインストールする。SQLiteのソースをSubversionのディレクトリに配置すれば,Subversionのインストール時に,一緒に組み込んでくれる(INSTALLファイルの12. SQLite参照)。しかし,独立性やパッケージ管理のしやすさを考えて,SQLiteも単独でインストールする。

    Source: SQLite Download Page

    LOCAL=~/.local
    cd $LOCAL
    wget -nc https://www.sqlite.org/2016/sqlite-autoconf-3130000.tar.gz
    tar xf sqlite-autoconf-3130000.tar.gz
    cd sqlite-autoconf-3130000
    ./configure --prefix=$LOCAL/stow/sqlite-3.13.0
    make && make install
    cd $LOCAL/stow; stow sqlite-3.13.0

    Subversion

    Subversionに必要な依存関係をインストールし終わったので,最後にSubversionをインストールする。

    Source:Download Apache Subversion Sources

    LOCAL=~/.local

    PKG=subversion
    VER=1.9.4

    cd $LOCAL/src
    wget -nc http://www-us.apache.org/dist/subversion/$PKG-$VER.tar.bz2
    tar xf $PKG-$VER.tar.bz2
    cd $PKG-$VER

    # 以下のとおりにsqliteのソース部分だけDLして配置すればSVNのビルド中に自動に組み込める
    # wget -nc https://www.sqlite.org/2016/sqlite-amalgamation-3130000.zip
    # unzip sqlite-amalgamation-3130000.zip
    # mv sqlite-amalgamation{-3130000,}

    ./configure --prefix=$LOCAL/stow/$PKG-$VER LDFLAGS=-L$LOCAL/lib
    make && make install
    cd $LOCAL/stow; stow $PKG-$VER

    最後に以下のコマンドでSVNのバージョンを確認できたら完了となる。

    svn --version

    これでSubversionがコマンドラインから使えるようになった。

    Doxygen vs. Sphinx+Breathe

    $
    0
    0

    ソースコードに埋め込まれたコメントから文書を生成するツールとして,DoxygenとSphinx+Breatheについて検討し,Doxygen単独での利用が妥当と結論づけた。そのことについてメモしておく。

    一連の考察は以下でまとめたツイートがベースとなっている。

    Doxygen vs. Sphinx+Breathe - Togetterまとめ

    Introduction

    ソフトウェアを開発していると,そのソフトのクラスの構成や使い方,概念などが複雑になってくることがある。また,会社など複数人で開発を行っていると,新しく参加する人のためであったり,数年後に忘れた時のために,APIの説明文書(API文書)があるととても役に立つ。

    しかし,こうしたAPI文書を作成する労力は無視できない。また以下の点も文書整備の妨げとなるだろう。

    • ソフトウェアの更新。
    • 文書整備の優先度の低さ。

    こうした問題があるため,文書の整備にかける労力はできる限り小さくしたい。これを実現する手段として,文書化ツールの利用がある。API文書の記述方法には,大きく2パターンが存在し,それに合わせて文書化ツールも分類される。

    • ソースコード中に記述(例:Doxygen)
    • ソースコードとは別に記述(例:Sphinx)

    この件については,以下のブログでも詳しい説明がある。

    リファレンスマニュアルの記述方法 - ククログ(2011-05-05)

    ソースコード中に記述する代表例はDoxygenであり,ソースコードと分離して記述する代表例はSphinxだと思う。

    基本的にはソースコード中に記述する方法のほうが,書き漏らしがなく,ソースコードのすぐ近くで説明をかけるので,労力が少ないだろう。つまり,DoxygenのほうがAPI文書の作成には有利だ。しかし,文書の作成能力としては,Sphinxのほうが柔軟性が高いように思っている。Sphinxは世界中のOSSプロジェクトで採用されており,実績がある。また,Linux Kernelの文書でも採用されており,その利便性が気になっていた。

    SphinxでどうにかDoxygen(やソースコードに埋め込まれたDoxygen用のコメント)をうまく使えたらいいなと思っていた。DoxygenのマニュアルのUsing the XML outputでSphinxの拡張機能であるBreatheを使うことで,Doxygenの出力XMLをSphinxで使うことができると知った。そこで,API文書の作成にDoxygen単体とSphinx+Breathe (+Doxygen)のどちらがいいか検討してみた。

    Comparison

    DoxygenもSphinx+Breatheもあまり使ったことがないので,実際にサンプルを自分で作るのは難しい。そこで,Doxygen単体とSphinx+Breatheが実際に使われた事例をみることにした。具体的には以下のプロジェクトを参照した。

    Doxygen単体の事例
    Eigenソース
    Sphinx+Breatheの事例
    ITKExamplesソース

    例えば,以下のサイトで上記プロジェクトについて言及されていた。

    上記ページで,この他にも,Doxygen単体の事例として,OpenCVも上げられていた。

    比較には,最終成果物であるWebページ(HTML)と元ソースを使った。Webページがいくらきれいでも,元ソースに記載された記法が複雑であれば使用するのは難しいからだ。

    Result

    検討の結果,Doxygenのほうがよいと判断した。理由は大きく以下2点だ。

    • Doxygen単体で書かれたEigenの文書の品質が高く,Doxygen単体でも十分。
    • Sphinx+Breatheの実績が少なく,メリットに比べ導入の手間が大きい。

    Eigenでは,ソースコードとは別にdocディレクトリに説明文書だけを書いた.doxファイルが大量に配置されている。これらの.doxファイルで主に使い方な ど,APIとの関わりの少ないを見出しをつけて書いている。図表やサンプルコードがふんだんに盛り込まれており,非常に品質の高い文書で感動した。ただし,Doxygenコマンドもふんだんに使われており,Doxygenコマンドには存在しない表などはHTMLコードを書いているので,Doxygenに対する習熟が必要となる。

    この一方,Sphinx+Breatheの利点は以下2点だろう。

    • Doxygenで抽出したライブラリAPIの柔軟な配置
    • Sphinxによる柔軟な文書作成

    しかし,Eigenのマニュアルをみて,Doxygenで作られたAPI文書の品質についてはあまり問題にならなくなってしまった。また,Doxygenで抽出したAPIの柔軟な配置をうまく活用した文書の作成はノウハウがないので難しい。実際ITKexamplesでのSphinxの利用はいまいちだった。具体的にはソースコードごとに専用の.rstファイルを作り,そこで単にSphinxの指令を入力してAPIを表示させているだけだった。もう少し込み入った使い方ができないならば,Doxygenで表示させるのと同じで,手間だけが余分にかかっている。

    そのため,Sphinx導入に際して発生する以下の2点のデメリット以上のメリットが見当たらなくなってしまった。

    • reST記法の習熟
    • Sphinxの環境構築

    また,Breatheには以下で指摘されている通り問題がいくつかあるようだ。

    python - Has anyone used Sphinx to document a C++ project? - Stack Overflow

    Doxygenを採用すれば,記法や環境構築はDoxygenだけで済む。Sphinx+Breatheを使う場合でも結局Doxygenコメントを使うので,二度手間となってしまう。やはり,Doxygenだけにしたほうがいいだろう。

    余談だが,OpenCVも2系までSphinxを使っていた(Breathe拡張はなし)。しかし,3系からDoxygenに移行している。

    やはりメンテナンス性を考えるなら,Doxygenを使ったほうがいいのだろう。

    KaoriYa版Vimの独自設定を無効化する方法

    $
    0
    0

    WindowsにおけるVimとしては,KaoriYaで配布されているVim(KaoriYa版Vim)が日本では有名だ。

    KaoriYa版では使いやすいように公式とは異なるKaoriYa独自の追加設定がなされている。通常であれば,使いやすくなるので問題ないが,一部自分の設定に影響を及ぼしてしまう。このKaoriYa独自設定を無効化したくなったのでその方法を調べた。

    2016-08-17T22:00追記:確認にはVim 7.4.1944 +kaoriya (2016-06-20)を使った。

    端的に結論を書くと,以下のコマンドをコマンドプロンプトから実行して,KaoriYa版Vimと同じ場所に無効化のための設定ファイルを作ればいい。

    REM VIM変数にKaoriYa版Vimの配置場所を指定。例:C:\Users\senooken\local\opt\vim74-kaoriya-win64
    set VIM=%USERPROFILE%\local\opt\vim74-kaoriya-win64

    echo let g:vimrc_local_finish = 1 > %VIM%\gvimrc_local.vim
    echo let g:gvimrc_local_finish = 1 > %VIM%\vimrc_local.vim

    Table of Contents

    1. KaoriYa版Vimを普段使わない理由と使う理由
    2. KaoriYa版Vimの問題点
    3. KaoriYa版Vimの独自設定の無効化方法
    4. まとめ

    KaoriYa版Vimを普段使わない理由と使う理由

    個人としては,2年ほど前まではKaoriYa版Vim(GVim)を使っていた。しかし,途中からChocolateyでインストールできることに気づいたので,公式で配布されているVimに切り替えた。公式のVimに切り替えた理由は以下2点だ。

    1. 公式のインストーラーを使えば,右クリックにメニューが追加され便利。
    2. 派生版よりも公式を使ったほうが安心。

    第1の理由だが,公式版のVimをインストールすれば,ファイルを右クリックしたときに,[Edit with Vim]というメニューが表示され,これを選ぶことで素早くどんなファイルでもGVimで開くことができる。KaoriYa版GVimでは右クリックのメニューには登録してくれないので,右クリックメニューで使えるようにするには以下のどちらかの方法で自分で設定することになる。

    • 自分でレジストリーをいじって登録
    • 右クリック→[送る]の候補に登録

    後者の[送る]メニューへ登録するには,%AppData%\Microsoft\Windows\SendToディレクトリ(エクスプローラーのアドレスにshell:sendtoでもアクセス可能)にgvim.exeのショートカットを配置すればいい。この方法なら管理者権限も不要で簡単だ。しかし,[送る]メニューは右リックメニューの真ん中から下の方に表示されるので,アクセスしにくい。

    2016-08-16T23:30追記:なお,右クリックメニューにこだわらなければタスクバーに登録したアイコンからGVimを起動して,ファイルをGVImにドラッグドロップすることでも,素早くアクセスできる。しかし,GVimの起動のためにマウスカーソルをタスクバーに移動させると気が散るのであまりよくない。

    右クリックからGVimを使うときのメニュー

    第2の理由としては,KaoriRa版独自の設定は使わないほうがいいと思ったからだ。例えば,KaoriYa版のVimではfileencodingjapanという値を使える

    2016-08-16T23:30追記:コメントでの指摘のとおり,encodingの値としてjapanはVimの公式設定として利用可能な値だ(:help encoding-values)。ここは,KaoriYa版ではfileencodingsの値に,guessが使えるという記憶違いだった。KaoriYa版の独自設定は,当てているパッチをみれば原理的にはわかるらしいが,Vimのソースに関する知識がいるので理解するのは簡単ではない。公開日が2009年と少し古いが,以下の記事でKaoriYa独自機能について解説されているのでわかりやすい。

    KaoriYa 版で追加される機能まとめ - 永遠に未完成

    この記事で紹介されている通り,KaoriYa版どうかはif has('kaoriya') ... endifで判別できるので,KaoriYa版独自機能を使うならば,このように条件判定を行ってから使い,公式版のVimでも動作するようにしよう。

    しかし,当然ながらこの設定はVimのヘルプには掲載されていない。そのため,例えば,外人やVimをよく知らない人がこの設定をみたら意味を理解するのが極めて難しくなる。だから,このような公式で提供されていない非標準設定の利用は控えるべきだろう。

    上記2点の理由から普段はKaoriYa版Vimは使っていない。ただし,KaoriYa版Vimでなければならない場面が1箇所ある。それは,管理者権限が使えない場面だ。管理者権限が使えない状況というのは,例えば会社や共有のパソコンなどでの利用が想定される。管理者権限が使えなければ,公式で配布されているイン ストーラーでインストールすることができない。実際は,公式ではこのことを考えて解凍するだけで使えるバイナリ版も配布している。しかし,これは使わないほうがいい。なぜか?それは,公式の単独パッケージでは以下2点の問題があり極めて使いにくいからだ。

    • バージョンが古い。
    • syntaxやplugin,diff.exeなど通常であれば付属する標準設定・プラグインや標準コマンドが付属しない。

    このことから,管理者権限が使えない場面や,レジストリーを汚したくない,携帯性を高めたいという場面においてはKaoriYa版Vimを使うしかない。そのため,会社ではKaoriYa版GVimを使っている。

    2016-08-16T23:30追記:コメントでの指摘で初めて知ったが,現在の最新の公式のWindows版VimのNightly BuildがGitHubで配布されているようだ。ここからであれば,必要な付属品が全て同梱されたバイナリーが入手できることを実際にダウンロードして確認できた。指摘をくれたkaoriyaさんにツイートで教えてもらったが,VimのWebページではアナウンスしておらず,メーリングリストでお知らせがあったようだ。

    Releasesのページを確認したところ,2016-01-27のv7.4.1185からバイナリー版の配布を始めたようだ。約半年前の今年に入ってからなので比較的最近配布されるようになったようだ。

    KaoriYa版Vimの問題点

    しかし,KaoriYa版Vimでは前述の通り独自設定がなされており,場合によっては自分の設定と競合することもあるだろう。実際に僕には問題となった。具体的には,gvimrcで設定されているcolorscheme morningの設定だ。

    普段は~/.vimrcに以下の設定を記述することで,VimとGVimの両方でカーソル行を薄水色でハイライトするようにしている。

    set cursorline  " hightlight cursor line
    highlight CursorLine cterm=NONE ctermbg=LightCyan guibg=LightCyan

    公式のVimとGVimを使う限り,この設定で何も問題はない。しかし,KaoriYa版GVimでだけ,カーソル行のハイライトがmorningのカラースキームで上書きされてしまう。

    回避策としては,~/.gvimrcにも上記のハイライト設定を記述することで,KaoriYa版GVimで設定されたハイライト設定をさらに上書きする方法がある。しかし,公式版のVimでは正常に動作しているのに,日本独自のKaoriYa版Vimのためだけにこのような設定をするのは好ましくない。それに,今まで~/.vimrcの一箇所の設定だけで済んでいたのに,同じ内容を~/.gvimrcにも記述する必要があり,保守性が悪くなってしまう。

    2016-08-16T23:30追記:コメントでの指摘のとおり本来であれば,GVim固有の設定は~/.gvimrcに記述すべきであり,このことは以下のとおり公式でも推奨されている。

    The gvimrc file is where GUI-specific startup commands should be placed.

    :h gvimrc

    しかし,:highlightのハイライト設定に限れば,VimとGVimとで同時に設定でき,例えばcolorschemeの設定などで分けて書くのはあまり現実的ではない。だから,~/.vimrcの設定をそのまま使いたい。

    KaoriYa版Vimの独自設定の無効化方法

    幸いなことに,KaoriYa版の設定を無効化する方法があるので,この方法で対応する。

    無効化の方法は,KaoriYa版に付属するvimrcgvimrcの冒頭に記載されている。内容をまとめると以下の表のとおりとなる。

    Kaoriya版Vimの独自設定の無効化条件

    vimgvim
    グローバル設定
    • g:vimrc_local_finishの値が非0
    • $VIM/vimrc_local.vimが存在
    • g:gvimrc_local_finishの値が非0
    • $VIM/gvimrc_local.vimが存在

    ユーザー設定
    • g:vimrc_first_finishの値が非0
    • $HOME/.vimrc_first.vimが存在
    • g:gvimrc_first_finishの値が非0
    • $HOME/.gvimrc_first.vimが存在

    変数$VIMはKaoriYa版のvim.exeやgvim.exeの配置場所を表す。上記設定を簡単に実現するならば,例えばvimrc_local.vim内にlet g:vimrc_local_finish = 1と記述すればよい。ユーザー設定ファイル.vimrc_first.vimも一応使えるが,ホームディレクトリをあまり汚したくないのでグローバル設定で対処した。

    同様の設定をgvimrcに対しても設定すればいい。手作業でやってもいいが,面倒なのでコマンドプロンプトで以下のコマンドを実行してvimrc_local.vimを作成してやればKaoriYa版Vimの独自設定の無効化は完了だ。

    REM VIM変数にKaoriYa版Vimの配置場所を指定。例:C:\Users\senooken\local\opt\vim74-kaoriya-win64
    set VIM=%USERPROFILE%\local\opt\vim74-kaoriya-win64

    echo let g:vimrc_local_finish = 1 > %VIM%\gvimrc_local.vim
    echo let g:gvimrc_local_finish = 1 > %VIM%\vimrc_local.vim

    自分にはKaoriYa版のgvimrcの設定だけが問題だったので,gvimrcだけ無効化した。

    グローバル変数の設定だけで済むのならば,自分の~/.vimrcに以下を追記してやるだけで済む。

    let g:vimrc_local_finish  = 1
    let g:gvimrc_local_finish = 1

    この程度であれば,自分の設定で保持してもいいのだが,無効化にはファイルの存在までチェックしているので,面倒だがファイルを作るしかない。そのため,vimrc_local.vimg:vimrc_local_finishの設定も押し込めた。おそらく,このグローバル変数が他でも使われていることを心配して念の為二重にしているのだろう。

    まとめ

    KaoriYa版Vimの独自設定を無効化する方法をまとめた。こういったローカル設定に関する情報はあまりないと思うので,誰かの参考になるのではないかと思って記事にまとめた。

    KaoriYa版Vimは1999年から配布が行われており,約20年の歴史がある。日本でのVimの普及に大きな役割を担っていると思う。今後もVimを使っていくつもりなので,KaoriYa版Vimの動向もときどきチェックしていこうと思う。上記のKaoriya版独自設定の無効化にでは,グローバル変数だけでいいのではないかという意見も気が向いたらissueで質問してみようかしら…(遠い目)。

    Python "if __main__" in Node.js and WSH JScript

    $
    0
    0

    Pythonでは現在のプログラムが実行されていることを判別する構文がある。

    if __main __ == "__main__":
    print("module is runninng")
    else:
    print("module is included")

    __main__という特殊変数に,そのファイルが実行されていれば,"__main__"という文字列が格納されていることを利用している。

    これにより,ライブラリとして読み込んだ時と実行時とで処理を分けることができる。この構文により,例えば実行したらテストを動したり,サンプルの処理を行うことができ,そのファイル(ライブラリ)自体の動作の説明を行うことができる。ライブラリとして使うことを想定するプログラムでは便利だ。

    この構文をJavaScript(Node.jsとJScript)で実現する。

    if __main__ in Node.js

    Node.jsでは以下のどちらかの構文により実現できるようだ。

    if(require.main === module) {
    cocnsole.log('main module');
    }
    if(!module.parent) {
    console.log('main module');
    }

    参考:node.js equivalent of python's if __name__ == '__main__' - Stack Overflow

    if __main__ in JScript

    JScriptであれば,WScirpt.ScriptNameプロパティに現在実行中のプログラムのファイル名が入っているので,これを利用する。例えば,以下のように記述する。

    // \file hi.js

    if (WScript.ScriptName === "hi.js"){
    WScript.Echo("Hello");
    }

    Node.jsでの例と違い,自分自身のファイル名をハードコード(直接入力)しなければならず,少しいまいちなやり方となってしまう。しかし,こうしなければならない。つまり,以下のようにNode.jsでの例と同じように変数名の有無で判定すると,親から読み込んだ場合でも実行されてしまう。

    if (WScript.ScriptName){
    WScript.Echo("Hello");
    }

    なぜなら,親から実行した場合には,WScript.ScriptNameには親のファイル名が入っているからだ。

    これを確かめるには,以下のサンプルファイルを実行すればわかる。

    /// \file is_sample_main.js

    if (WScript.ScriptName){
    WScript.Echo('Failure');
    }

    if (WScript.ScriptName === "is_sample_main.js"){
    WScript.Echo("Not shown");
    }
    <?xml version="1.0" encoding="UTF-8"?>
    <!-- \file is_sample_main.wsf -->
    <package>
    <job>
    <script language="JScript" src="is_sample_main.js"></script>
    </job>
    </package>

    上記2ファイルを作成して,is_sample_main.wsfをダブルクリックか以下のコマンドでコマンドプロンプトから実行する。

    cscript.exe -nologo is_sample_main.wsf
    Failure

    is_sample_main.wsfでは,is_sample_main.jsを読み込んで実行しているので,is_sample_main.wsfは親ファイルとなる。そのため,WScript.ScriptNameで条件分岐させた処理は実行してほしくない。しかし,WScript.ScriptNameだけの条件分岐に入り,実行されてしまっていることがわかる。

    参考:javascript - JScript - How to know if the script was activated using WSH or internally by another script? - Stack Overfl

    Create Library

    ここまでで,Node.jsとWSH JscriptでPythonのif __main__ == "__main__"を実現する方法を示してきた。ただ,毎回手作業で書くには少々長い。そこで,これを実現する関数を作ってライブラリ化してみる。

    /****************************************************************************
    \file is_main.js
    \author SENOO, Ken
    \copyright CC0
    *****************************************************************************/

    function is_main(this_file_name){
    return (typeof(module ) !== "undefined"&& !module.parent ) ||
    (typeof(WScript) !== "undefined"&& WScript.ScriptName === this_file_name)
    }

    if (typeof(print) === "undefined"){ // for SpiderMonkey
    function print(text){
    if (typeof(console) !== "undefined") console.log(text );
    else if (typeof(WScript) !== "undefined") WScript.Echo(text);
    }
    }

    if (is_main("is_main.js")){
    print("Hello");
    }

    上記のis_main.jsでは,is_main関数を定義している。引数に自分自身のファイル名を渡せば,Node.jsとWSH Jscriptの両方のif __main__ "== __main__"を評価してその結果を返してくれる。汎用化させるために,条件式の最初にNode.jsやWScirptが使えるかどうかを判定している。

    また,後半では以前以下の記事で作成したprint関数を再掲している。これにより,コード末尾の自分自身が実行されている時だけメッセージを表示させることを,Node.jsでもWSH Jscriptでも動作するようにしている。

    My Future Sight for Past: JScriptのWScript.Echo()とJavaScriptのconsole.log()の共通化

    Conclusion

    JavaScriptであるNode.jsとWSH JScriptで,ライブラリ自体が実行されているかを判別するPythonのif __main__ == "__main__"を実現する方法を紹介した。今後これらの言語でライブラリを作成するときは活用してみたいと思う。今回紹介したコードはgistでも公開しているので必要に応じてダウンロードしてほしい。

    GitHub GIst: Python "if __main__" in Node.js and WSH JScript

    How to check root user in shell script

    $
    0
    0

    シェルスクリプトなどで現在のユーザーがルートユーザー(root権限,管理者権限,スーパーユーザー,super user)であるかを判別する方法を記す。

    例えば,システムやデバイスの操作を行いたい時には,sudosuコマンドによりルート権限を取得してからコマンドを実行する。これをシェルスクリプトで実装するには,スクリプト内で現在のユーザーがルートユーザーかどうかを判定して,ルートユーザーでなければ処理を中断させるのが一つの方法だ。そこで,現在のユーザーがルートユーザーであるかを判別する方法が必要となる。

    結論を書くと,以下のPOSIX準拠の構文により実現できる。

    if [ $(id -u) = 0]; then
    echo "I am root user: $(id -nu)."
    fi

    root権限ではuser ID(UID)が0であることがPOSIXで保証されていることを利用している。このことは,WikipediaのUser identifierのページで言及されている。引用元のPOSIXのgetpwuidコマンドのページを確認すると,以下のとおりに確かにroot権限ではUIDは0となると明記されている。

    The following example gets the user database entry for the user with user ID 0 (root).
    getpwuid

    UIDの取得にはPOSIX準拠コマンドであるid -uにより取得できる。ユーザー名の取得は-n(name)オプションを一緒につければ取得できる。

    ネットの情報だと,他にもUID変数やEUID変数,whoamiコマンドを使ったり,ルートユーザー名がrootであることを利用した判別を行っている。

    参考:

    しかし,これらの変数,コマンド,名前はPOSIXで未定義なので,他の環境での動作が保証できない。そのため,特に他の理由がなければ,[ $(id -u) = 0 ]により判別すべきだろう。

    Viewing all 265 articles
    Browse latest View live