Neovim なのかなぁ,やっぱ,って

最近とうとうそんなことを考えるようになってしまいました.

でもまだちょっと迷っていたりするのですがね.

今朝のアップデートでどうやら解決された模様.;

この話後でも触れるつもりなのですが,実はずぅっっっと気になっていた症状で,ひとまずは安心.

あれ? と思ったのは,macOS Sierra にした時か,MacVim が Ver8.0 になった時か忘れちゃったのですが,それ以来なので結構時間掛った感あり.
日本(語)でのレポートがヒットしなかったので,自分の環境が悪いのかと心配していたのですが*1これを見つけちょっと安心し,その遣り取りを物陰から祈るよう,ひっそりと見つめておりました.

f:id:wooweezoowee:20161123114102g:plain

でも transparency が上手く効いていない模様 orz...

今度こそは,自分の設定のどっか悪いのかな,と心配になっていたりします.

試しに Neovim

と言うことで,どんなもんなのだろう,と試しにインストールをし,そして現 Vim での作業環境を Neovim へ展開するところまでを試してみることにしました.

今回はそんな中でのメモを残しておこうと思っています.

作業環境はこんな感じです.;

% sw_vers
ProductName:    Mac OS X
ProductVersion: 10.12.1
BuildVersion:   16B2555

% system_profiler SPHardwareDataType
Hardware:

    Hardware Overview:

      Model Name: MacBook Pro
      Model Identifier: MacBookPro9,2
      Processor Name: Intel Core i5
      Processor Speed: 2.5 GHz
      ...

そして homebrew の環境あり,です.

*1:os も 2 回入れ直した程.

続きを読む

"TODO:" を目立たせたいと思った、どのファイルでも

タイトルの通り、"TODO" とか "NOTE" とか、そんな目印を目立たせたい、と。
しかもここでは、ファイルタイプ関係なく*1、どのドキュメントにおいても一律、全て同じスタイルのハイライトで構わない、というかむしろそうしたいと考え、その方向で検討しています。

結果、.vimrc の任意の箇所に以下のよう、設定を施しました。;

" コメント中の特定の単語を強調表示する
augroup HilightsForce
  autocmd!
  autocmd WinEnter,BufRead,BufNew,Syntax * :silent! call matchadd('Todo', '\(TODO\|NOTE\|INFO\|XXX\|TEMP\):')
  autocmd WinEnter,BufRead,BufNew,Syntax * highlight Todo guibg=Red guifg=White
augroup END

指定の文字列のアルファベット部は全て大文字で、かつ直後にコロン : で結んだ場合にのみハイライトされるようにしています。
これは単に個人的な好みの問題です。

例えば "TODO" の場合。

単に "TODO" とタイプしてもハイライトはされません。コロン ":" がないので。
また "todo:" とか "Todo:" 等と、大文字-小文字が異なってもハイライトされません。

この度、この度参考にさせていただいた主なリソースは以下の通りです。
有難い。感謝です。;

» In vim, how do I highlight TODO: and FIXME:? - Stack Overflow
» Vim : Highlight the word TODO for every filetype - Stack Overflow
» ちくパ — Vimでどんなファイルタイプでもコメント中の特定の単語をハイライトする

と言うことで、今回の作業で知ったこと、感じた事メモ。

*1:現時点での自分の作業スタイルを考えると、キーワードに対するハイライトをファイルタイプ単位で切り分けると言う事に余り意味を見い出せないかな、と感じたのがあります。これは人それぞれだと思います。

続きを読む

`[ "$a" == "$b" ]` ですって?!

とある切っ掛けをもって,この際あらためて整理しておこうと思ってのメモ.

お話は shellscript .

思ったより長くなってしまったので...

tl;dr

  • [ "$a" == "$b" ] って言ってるの見た
    test コマンドなり [ では == はダメじゃなかったっけ? (今までの自分が幽体離脱)

  • 否,=== もどちらも正解
    "等しかったら" のオペレータとしてどちらも正しい,と言うのを知ったのですorz

  • ただしシェルによる
    これ POSIX 準拠の話.

  • POSIX を考慮するなら = を使っといた方が良いらしい
    == ではなく.

  • ここでは [ x = y ] で統一することに決めた
    [ x == y ] な書き方は当方ローカルルールとして違反とする.

でいいかな.

=? ==?

別件でたまたま踏み入れたページで目にした,こんな記載.;

[ "$a" == "$b" ]

震えが止まらなくなる.

ずっと [ x = y ] だと思って書いてきた.

なぜならそれが正解で,== はむしろ禁じ手とまで思っていたほど.

え?! これって間違い?

一気に,色々と気になり出す.

結果として分かったこと

まず...

両方ともに正解

どっち (で) もいい.

test コマンドにて "同じだったら" を評価する際の演算子として, = 使うも == を使うも,どちらもアリ,ということらしい.

string1 == string2
string1 = string2
    文字列が同じならば真となります.POSIX に準拠する形で test コマンドを使う場合には = を使う必要があります.

GNU Core Utilities (Coreutils) のドキュメントがあって,こちらではより明確に "同じ" と記載されています.;

‘string1 = string2’
    両文字列が等しければ,真.
‘string1 == string2’
    両文字列が等しければ,真 (= と同じ意味).

冒頭の「== は禁じ手とまで思っていた」と言う,その思い込みこそが間違い.

じゃぁ.

この擦り込みは一体何処から...というのが気になるところ.

で,思い起こしてみると,ここかと.

シェル,zsh 使ってるから

随分と前に,《test コマンドの文字列比較演算子の "等価" は == ではなく =》と言ったことを書いたことがありまして.

そこでは = not found なるエラーに遭遇.

そしてその原因は [ x == y ] なる書き方をしたが故のものだった,と言うものでした.

思えばその "擦り込み" は,この出来事がキッカケだった,と.

この時の苛立ちを発端にスボラな性分も助け,何の根拠を求めることなく極端に,== を "禁じ手" と自己洗脳することで,自分の中で整合をはかった,と.

ここで見えてきたことは,test コマンドおよび [ の条件式にて,x == y と言う書き方はシェルによって*1受け付けてくれないようですよ,と言うことかと.

丁度良いレポートが目に留まったので引用させていただきますと.;

まずはbashで以下を実行.
    $ [ a = b ] && echo true || echo false
    alse
    $ [ a == a ] && echo true || echo false
    true
同じコマンドをdashで実行.
    $ [ a = b ] && echo true || echo false
    false
    $ [ a == a ] && echo true || echo false
    [: 4: a: unexpected operator
    false
zshでもdashと同様の結果になりました.

両方ともに正解,だけどシェルによって違ってくる

って言ってしまってよいのでしょうか?

ここまでの話ですと,
= そして ==,どっち用いるも正解,と言えるのは,シェルによる,となるのでしょう.

その "正解" は,
bash だから成り立つもので,
zsh では成り立たない,となるのでしょう.

先に "どちらも正解 (同じ)" の根拠として引用した引用先は,いずれも bash のものでした.
そして "== はだめ (違う)" と見られたのは,zsh 上での話.

じゃぁ,bashzsh の違いからの問題か,と言いますと,おそらく正しくはソコではなく...

両方ともに正解,だけど POSIX 準拠を考慮するか否かによって違ってくる*2

POSIX が云々,と言う切り口は,これまでの引用箇所からも度々チラついてましたが改めて.;

POSIX に準拠する形で test コマンドを使う場合には = を使う必要があります.

[ x == y ] だと怒られる時があるけど,[ x = y ] と書いてれば怒られることはない,らしい.

とはいえども,実際のところどうなんだ,と言うのを知りたかった.

世の中はこの === かの摘み分けをどう扱っているのだろう.

って...



GraphViz Example: shells.dot
GraphViz Example: shells.dot / kentbye



*1:自分の場合は "zsh なので" となるでしょう.

*2:POSIX 仕様のシェル,とか POSIX 準拠のシェルとか,って言ってよいのかな.この辺りが自信無かったので.

続きを読む

コマンドラインで caps lock キーを潰す.control キーに. -- macOS Sierra (v10.12)

macOS の環境設定は,GUI ではなく defaults コマンドなりを並べた shellscript を走らせて行っておりまして,今回はそこでのお話.

そのうちのひとつ,Caps Lock キーを control キーにする設定を施しているのですが,これができていない様子.

思った通り,Sierra (v10.12)になってやはり上手く設定ができなくなっているアイテムはあるけれど,選りによって面倒くさいところで引っかかってくれた.

正直ダルい.

覗いてみると,どうやら制御に必要なキーボードの情報,いわゆる "keyboard ID"*1,が上手く取れていないようで,これが原因っぽい.

ちなみに使用しているマシンは powerbook pro 13".Mid 2012.レガシーw
us キーボード.

結果こうしました.;

# キーボードID
keyboardid="keyboardid=$(ioreg -c AppleEmbeddedKeyboard -r | grep -Eiw "VendorID|ProductID" | awk '{ print $4 }' | paste -s -d'-\n' -)'-0'"
# Capls Lock キーを control キーにする.
defaults -currentHost write -g com.apple.keyboard.modifiermapping.${keyboardid} /
    -array-add /
    '<dict>
      <key>HIDKeyboardModifierMappingDst</key>
      <integer>2</integer>
      <key>HIDKeyboardModifierMappingSrc</key>
      <integer>0</integer>
    </dict>'
# [システム環境設定 > キーボード > 修飾キー > Caps Lock キー] => [^ Control]

defaults の箇所は実際 1 行で書いてます.
ここでは見易さを考え,ちょっと整形することにしました.

問題は IOHIDKeyboard がなくなった,ってこと?

で,良いのですか?...というか,っぽいのですが.

いやいや,こう言うことってあるの?と,素人目には正直ちょいと信じがたいレベルだったりするのですが...

話を進めるのに,以前のコードを置いて始めた方が早いかな,と.

これまで

こんな感じでした.;

keyboardid=$(ioreg -n IOHIDKeyboard -r | grep -E 'VendorID"|ProductID' | awk '{ print $4 }' | paste -s -d'-\n' -)'-0'
defaults -currentHost delete -g com.apple.keyboard.modifiermapping.${keyboardid}

Sierra (v10.12) になって

キーボードの情報,上のコードですと ${keyboardid} という変数に期待している値が入って来てない様子.

覗いてみると結果はブランク.

以後,Apple オフィシャルではありませんが "伝わりやすいかな" という感覚でこちらに倣って,便宜的に,"keyboard id" と呼ぶことにしようかと思います.

f:id:wooweezoowee:20161003184134p:plain

*1:Apple やらのオフィシャルの用語ではないようです.

続きを読む

ソレをどこに置いたらいいか迷ったけど,そもそもソレじゃないかも,って話

$(command) & なのか $(command &) なのか,どっちなんだろ?と思った時,手が止まった.

ら.

どうやら,こういうのって駄目みたい.

そうなの?

ちなみに今回,初めから言っておきますと,ハッピーエンドではありません.

この壁は自身が弱者ゆえのものであるかもしれません.

キーワードは,
コマンド置換 $(command)バックグラウンドでの実行の制御演算子 &直前の処理のプロセス ID を拾う $!,そして wait コマンド,と言ったところになるでしょうか.

続きを読む