`[ "$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 上での話.
じゃぁ,bash と zsh の違いからの問題か,と言いますと,おそらく正しくはソコではなく...
両方ともに正解,だけど POSIX 準拠を考慮するか否かによって違ってくる*2
POSIX が云々,と言う切り口は,これまでの引用箇所からも度々チラついてましたが改めて.;
POSIX に準拠する形で test コマンドを使う場合には = を使う必要があります.
[ x == y ]
だと怒られる時があるけど,[ x = y ]
と書いてれば怒られることはない,らしい.
とはいえども,実際のところどうなんだ,と言うのを知りたかった.
世の中はこの =
か ==
かの摘み分けをどう扱っているのだろう.
って...
GraphViz Example: shells.dot / kentbye
コマンドラインで 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" と呼ぶことにしようかと思います.
ソレをどこに置いたらいいか迷ったけど,そもそもソレじゃないかも,って話
$(command) &
なのか $(command &)
なのか,どっちなんだろ?と思った時,手が止まった.
ら.
どうやら,こういうのって駄目みたい.
そうなの?
ちなみに今回,初めから言っておきますと,ハッピーエンドではありません.
この壁は自身が弱者ゆえのものであるかもしれません.
キーワードは,
コマンド置換 $(command)
にバックグラウンドでの実行の制御演算子 &
,直前の処理のプロセス ID を拾う $!
,そして wait
コマンド,と言ったところになるでしょうか.
行番号は gvimrc でいいんだろか
どのカラースキームを使っても,行番号はもう少し目立つようにしたいと思うようになりました.
結果 gvimrc
の任意の場所に,以下のような記述を追加しました.;
" 行番号はどの colorscheme 使っても一律目立たせる highlight! CursorLineNr gui=NONE guifg=#f5f5f5 highlight! LineNr guifg=#949494
気になるのは,この設定を定義する先.
.gvimrc
に書くのが果たして正しいものなのかは,ちょいと自信無い.
ちなみにその根拠は,文字の色と言った "見た目" をコントロールする設定なので .vimrc
ではなく .gvimrc
かと.
定義した場所が rc ファイルだけに,どのカラースキームを使っても同じになりますが,現時点これで良しとしています.
あと自身,おおよそ gVim しか使わない島の人間で,尚且つ "その設定がどう効くのか良く分かっていない" と言うこともあり cterm
の方は意識的にうっちゃってます(笑)*1.
やっぱ $VIMRUNTIME/syntax/...
のどっかで定義するのがスマートなのかなあ...
*1:決して望ましくないのは分かるのですが,良く分からずに何となく設定することの気持ち悪さと,それ以上に普段の利用において特に支障を感じない,というのがあるので良しとしてます.本当に「必要」と思った時に,改めてきちんと考えるで良いかなあと.
出てこいっ 「.vimrc も mru としてリストに現れるように」
またやった...
「まさかこれはないだろう」が実はソレ,って言う.故,壮大に何一つ意味の無い無駄な廻り道.
今回のお話は Unite.vim の neomru.vim.
未来の自分の為に,何でこんな設定をしたのか,のメモ.
.vimrc も mru ファイルのアイテムとしてリストに揚がるようにしたい
こうなりますか ?
g:neomru#follow_links = 1
あまり自信無かったりもしますが,一応願った通りの振る舞いをしてくれています,ということで :-P
キッカケ
.vimrc を色々触っている時のこと.
:Unite file_mru
した時に*1,この .vimrc ファイルも mru ファイルとしてリストアップされるようになってほしいと考えました.
*1:実際はマップをしてますが