最近の変更サイトマップ

EmacsのTRAMPのrgrepでfind: paths must precede expression: ^^!^が出るようになった顛末

Windows 10 + PuTTY(plink) + Emacs 26.1な環境でLinuxターゲットのSSH TRAMPがいい感じに使えてたんだけど、PuTTYをmsys2のものに置き換えたら、rgrepが「find: paths must precede expression: ^^!^」なるエラーを吐いて使えなくなってしまった。これじゃ仕事にならん!ってなもんで前のPuTTYに戻したものの状況は変わらず…オワタ\(^o^)/

とりあえずemacs/share/emacs/26.1/lisp/progmodes/grep.el.gzの1153行目付近、-prune -o(shell-quote-argument “!”)から文字列を結合してるあたりを削り、M-x byte-compile-file grep.el.gzして、超無理やり解決した。

同様の問題が起きた時の参考として、解決に至るまでの顛末をメモ。

  • lgrepやgrep-findは動くのでrgrepの問題と判断。
  • エラーメッセージと*grep*バッファのコマンドログから -prune -o ^“^!^” -type d あたりが怪しいと判断。実際、^“^!^”の先頭のサーカムフレックスは引数の文字としておかしくない?
  • M-x describe-function rgrepでrgrep関数の定義を探す→grep.el.gzと判明
  • ファイル内を「rgrep」をキーワードに流し読み。rgrep-default-command関数で実行するコマンドを組み立ててる予感!
  • 一応scratchバッファで(rgrep-default-command “XXX” “YYY” “ZZZ”)を実行して結果を見てみる→あたり!
  • rgrep-default-command関数の中で「!」を使ってるところを探す→(shell-quote-argument “!”)発見
  • scratchバッファで評価してみる→変なエスケープのされ方をされている!
  • 「!」は結合しない方向で、findの引数の関係が正しくなるように前後の処理を調整
  • M-x byte-compile-file grep.el.gzしてEmacs再起動
  • rgrepが使えるようになっていることを確認

根本原因はshell-quote-argumentの挙動が変わった(?)ことっぽいけど、なぜ変わったのかは不明のまま。PuTTYを差し替えたこと以外、何もいじってないはずなんだけどな…。

同様にshell-quote-argumentの実装を見てみても、OSによって処理を分岐させてるだけで変なところはない。……ん?待てよ、TRAMPの場合はOSはどういう扱いになるのこれ?ちゃんとリモート側のシステムにあわせてsystem-typeの中身が変わるのこれ…?

2018-12-04 追記

サーカムフレックスはコマンドプロンプトでのエスケープシーケンスらしいので、TRAMPしてるにもかかわらずshell-quote-argumentがWindows用の挙動を示すのが根本原因のようだ。

先の回避策では除外ディレクトリの指定が効かなくなってしまうので、grep.el.gzの1153行目あたりを以下のように変更した。

    (and grep-find-ignored-files
         (concat (shell-quote-argument "!") " -type d "

    (and grep-find-ignored-files
         (concat " '!' -type d "

Lightroomでユーザー権限も問題が発生しました。

MacでLightroomを起動したら「Lightroomでユーザー権限の問題が発生しました。」というエラーダイアログが表示された。

「修復して続行」ボタンを押しても「権限の問題を自動的に修復できません。」とつれない返事。

仕方ないので詳細情報をクリックしたら、英語の解説ページに飛びやがんの。Adobeの代わりに日本語のページも張っておきまつね。

直し方は解説ページのとおりで、次のディレクトリのパーミッションを修正してやればよい。

  • ~/Library/Preferences/
  • ~/Library/Application Support/Adobe/
  • ~/Library/Caches/Adobe/
  • ~/Documents/Adobe

~/ってのは自分のユーザーディレクトリを表す表記で、いわゆる「/Users/ユーザー名/」の事。正式な表記なので覚えておくと便利だよ。

~/Libraryは隠しフォルダでありFinderには通常表示されない。Finderメニューの「編集>フォルダへ移動」で開くダイアログに「~/Library」と入力し「移動」すれば表示できる。「~/Li」まで打ってTABキーを押すと「~/ライブラリ」という具合に入力補完してくれるので便利だよ。

このとき、正しく~/Libraryと入れているにもかかわらず、なぜかシステムのライブラリフォルダ(/Library)が表示される事があるので要注意。また、LibraryとDocumentsは日本語版ではそれぞれ「ライブラリ」「書類」という表記になる点にも注意されたし。どうしてもユーザーライブラリフォルダに移動しない時は、ターミナル.appを開いて「open ~/Library」を実行すれば開くよ。

あとは各フォルダの「情報を見る」で以下の項目の確認&設定をする。変更する時はおなじみ南京錠マークをクリックしてね。

  • 「共有とアクセス権」で、自分のユーザーアカウントに「読み/書き」のアクセス権があるか。なければ追加&変更。
  • 歯車アイコンをクリックし、「内包している項目に適用」をクリック。

2つ目の「内包している項目に~」がとても重要。前述の各ディレクトリのアクセス権は正しいものの、格納されているファイル/フォルダのアクセス権が原因の事が往々にしてある。今回の当方の原因もそうだった。

FreeBSDのmail/courierが0.65止まりなのは依存パッケージの問題

変人御用達の Courier Mail Serverのバージョンが、9月にめでたく1.0の大台に乗っていた。

その一方、FreeBSDのportsのmail/courierは何年も0.65止まり。メンテ自体は行われていて、0.65.3のまま周辺環境の変更に追従している感じ。なぜ本体のバージョンアップを行わないのか不思議だったんだけど、MLによれば、メンテナが他の件で忙しいのと、0.65より新しいCourierは依存関係が増え、その解消のために新たなportsを作らなきゃならんのが原因らしい。まぁ、その投稿(2014年)から4年が経つわけですがね…。

早く追従してくれないかなー(人任せ

DT4282の1000V/0.63Aヒューズを飛ばして痛い目をみた

日置のマルチメーターDT4282の電流レンジでJ-FETの選別をしてた際、誤ってプローブをショートさせてしまった。ピーッという音と共に画面が赤くなり最初は何事かと思ったが、測定値が出ないのを見てなるほどガッテン、ヒューズが飛んだんだなと。秋葉原に行くのが面倒で秋月通販したばっかなのに、結局ヒューズ1本のために出向くことになるのかチクショーなどと思いつつテスターを開けると、なんか見たことないヒューズが入ってるんですけど。

白くてデカくて見るからに高そうな雰囲気(写真上。下のは比較用のミゼットヒューズ)。大きさは実測37.95mm×10.31mmなので、38mm×10.3mmないし38mm×10mm規格のセラミック管ヒューズと思われる。定格の1000V/630mAで検索してみたが、販売店が日置の公式ショップしか出てこないという…。しかも1本860円(税抜き)と超高い!普通のヒューズの10倍以上だよ!!その上、送料540円が加算される罠。貧乏人の味方、eBay、AliExpressでも適合品見つからないしまぢ詰んだ。ここでトンでもないミスをやらかしたんだと思い知らされた。ヒューズが飛んだだけに。

送料かかる位なら秋葉原まで行くわ、ってもんでラジオセンターのHIOKIショップに行ってみたら在庫なしで取り寄せになってしまった。結局、発注と受取の電車2往復で540円より高く付いた\(^o^)/まぢつらたん。

左が飛んだヒューズで右が買ってきたやつ。印字の色が違うけど問題はないそうで。まぁ定格が合ってるんだから当然か。モノ自体はHOLLYLANDのヒューズっぽいけど、ほぼHIOKI専用品のようだ。まぁ、サイズが適合する元の定格より低い安物で代用できると思う。1000Vなんてまず使わんし500V0.5Aとかので大丈夫じゃね?

電流レンジを使うときは、ちゃんと電流制限機構を入れないとダメですな……人は失敗によって成長するのだ………。

InnoDB File-Per-Tableモードではinnodb_data_home_dirは無視される

MySQL/MariaDBにinnodb_data_home_dirというシステム変数がある。InnoDBのデータファイル置き場を明示する変数だが、InnoDB File-Per-Tableモードでは指定値が無視される。File-Per-Tableモードとは、InnoDBのテーブル毎にファイルを作成するモードの事でinnodb_file_per_table変数で制御可能である。MySQL 5.6.6以降でデフォルト有効になったため、innodb_data_home_dirは事実上意味がなくなってしまった。

よって、File-Per-TableモードではZFSのrecordsizeprimarycacheをストレージエンジン毎に最適化する、という手法が取りにくくなった。(DBごとにフォルダが作成され、その中にInnoDBやMyISAMのファイルが混在することになるため。)自分のメモも兼ねて最適とされるパラメータを下表にまとめる。

ストレージエンジン recordsize primarycache
MyISAM 8kBall
InnoDB(データ) 16kBmetadata
InnoDB(ログ) 128kBmetadata

参考サイト

start.txt · 最終更新: 2016-05-07 17:46 by Decomo
CC Attribution-Noncommercial-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0