ToDo:
だらだら書いてみたわけだけど、 同じようなことを GCC とか Emacs とか Xen とか Qemu とか valgrind とか なんでもいいけどまぁ他のプロジェクトであるといいなぁ。
(05:10)
stat が遅いということがあって、 長い間こんな ls を使っていた。 要は 2回 ls をして、最初の ls で 500 エントリ以上あると判明したら 色つけたりをやめる。 stat が 500 回とか当時のマシンでは相当キツかったから。 LS は vanilla ls ね。
ls () { if [ `LS -B $@ >/dev/stdout >&/dev/null | wc -l ` -le 500 ] ; then LS -F --color -B $@ else LS -B $@ fi }
今時こんなもん意味あるんだろうか… そもそも dirent の d_type 見てくれたりしてくれんの? ということで strace してみる。 すると見事に stat 呼んでない。 coreutils の ls.c も適当に読んだところ、 たぶん DT_UNKNOWN とかじゃなければ基本 stat 呼ばない気がする。 よってこんなハックもういらない。
どうでもいいけど ls.c のこの if 文は力作すぎる
if (command_line_arg || format_needs_stat /* When coloring a directory (we may know the type from direct.d_type), we have to stat it in order to indicate sticky and/or other-writable attributes. */ || (type == directory && print_with_color) /* When dereferencing symlinks, the inode and type must come from stat, but readdir provides the inode and type of lstat. */ || ((print_inode || format_needs_type) && (type == symbolic_link || type == unknown) && (dereference == DEREF_ALWAYS || (command_line_arg && dereference != DEREF_NEVER) || color_symlink_as_referent || check_symlink_color)) /* Command line dereferences are already taken care of by the above assertion that the inode number is not yet known. */ || (print_inode && inode == NOT_AN_INODE_NUMBER) || (format_needs_type && (type == unknown || command_line_arg /* --indicator-style=classify (aka -F) requires that we stat each regular file to see if it's executable. */ || (type == normal && (indicator_style == classify /* This is so that --color ends up highlighting files with these mode bits set even when options like -F are not specified. Note we do a redundant stat in the very unlikely case where C_CAP is set but not the others. */ || (print_with_color && (is_colored (C_EXEC) || is_colored (C_SETUID) || is_colored (C_SETGID) || is_colored (C_CAP))) )))))
{
でまぁ NFS なんだけど、 NFS だと結構 DT_UNKNOWN がかえってくるみたいだ。 一見して一回 stat したら cache されて その情報で d_type 埋めてる、って感じかなぁ。 となると worst case で stat 呼びまくるのはさけがたい感じなのかなぁ…
一番うざいのは zsh & nfs でたまに補完がすごい遅いという話で、 zsh はどうも d_type とか気にせず stat 呼びまくってるっぽいんだよなぁ。 コードちょっと読んだけどイマイチよくわからず。 NFS で最悪状況でのパフォーマンスが良くならんとわかったのもあってやる気失せてきた
(22:38)
LS -B $@ >/dev/stdout >&/dev/null
ってなんだろう。なんで
LS -B $@ 2>/dev/null
じゃないんだろうか。 まぁ書いたの10年くらい前だろうし shell のシの字くらいもわかってなかったのかもしれず
(22:40)
charset セットしてくれてないサイトで WebKit は化けるんだけど、 まぁいいかげん detection ぽいの作ろうと。 どうやればいいのかよくわからんかったのだけど、 とりあえず以下のを Chrome key に読ませたら動いた。 とりあえず牧野先生のところとその他もろもろでそれなりに動くから良しとする。
var CHARSETS = ["Shift_JIS", "EUC-JP", "UTF-8", "ISO-2022-JP"]; var currentCharset = document.charset; var bestText = ''; var bestScore = 20000; var bestCharset = currentCharset; for (var i = 0; CHARSETS[i]; i++) { var charset = CHARSETS[i]; if (charset == currentCharset) continue; var http = new XMLHttpRequest(); http.overrideMimeType("text/html; charset=" + charset); http.open("GET", location.href, false); http.send(); var text = http.responseText; var last = text.length; if (last > 10000) last = 10000; var bakeCount = 0; for (var j = 0; j < last; j++) { if (text.charCodeAt(j) == 65533) bakeCount++; } console.log(charset + ": " + bakeCount); if (bakeCount == 0) { document.body.innerHTML = text; document.charset = charset; return; } else if (bestScore > bakeCount) { bestScore = bakeCount; bestText = text; bestCharset = charset; } } document.body.innerHTML = bestText; document.charset = bestCharset;
(23:31)
前 | 2010年 1月 |
次 | ||||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
31 |
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。