ついにこの季節か……という訳で、個人的に気になった Advent Calendar をリストアップする試み。
続きを読む2013年11月09日
2013年10月16日
(10 - 5) "type" Command Examples to Manage Files in Windows
大分前になるけれど、上記の記事で、 Linux / Unix で用いられる「cat
」コマンドの使われ方について紹介されていた。
cat
は、専らファイルの内容の出力に使われているイメージがある。しかし、cat
は「concatenate」(連結する)の略であり、本来はファイルを連結する為のコマンドだった(らしい)。
Linux / UNIX のcat
に似たWindowsのコマンドとして「type
」が在る。このtype
コマンドでも、上記記事で紹介された使い方の一部は実現出来る。以下でそれらを紹介する。
なお、type
はMS-DOSにも存在するが、そちらではどうかは確認していない(確認出来る環境が手元に無い)。
続きを読む
2013年07月31日
PowerShellの起動時に指定したオプションを取得する(そして対話的な実行かどうかでモジュールを読み込むかどうか切り替える)
コマンドラインシェルの用途は2つ在る。対話的に処理させる場合と、バッチ処理させたい場合だ。バッチ処理用に起動した場合に、対話的環境での利用を想定した処理を行うのは無駄だ。例えばPowerShellでの場合、バッチ処理時にPowerTabモジュールを導入するのは意味がない。むしろ、その為の処理リソースを取られる事になるので、出来る限り避けたい。
続きを読む2013年05月21日
Windows Script Host から Windows PowerShell へ
先日Windowsの環境変数について調べた際に、久しぶりにWSH用のJScriptを書いた。WSHはMicrosoftが提供するWindows用のスクリプト実行環境だ。
WSHの利点はWindowsにプリインストールされているという事だ。Wikipediaに拠ると、 Windows 98 以降であれば確実に入っているという。(RubyやPerl等とは異なり、)別途実行環境を用意する必要がないので、作成したスクリプトを配布する際にとても便利だ。
しかし、今となっては甚だ時代遅れで使いづらい。例えば配列の全要素を舐めるのに Array.forEach()
が使えなかったり。現代のJavaScriptに触れていると、「あれも無い、これも無い」という点が気になってしまう。
流石にこれではキツイ。そこで Windows PowerShell に目を付けた。PowerShellはMicrosoftが新たに開発したコマンドラインシェル環境だ。これがまぁ意外と良い感じ。 Windows 7 からはプリインストールされているらしいし、将来的には導入コストは0になるだろう。
勿論、WSHはスクリプト実行環境でPowerShellはシェル環境なので、単純に比べられる物ではない。WSHとcmd.exeを合わせたものと比べるべきなのかもしれない。今までこの2つで行っていた作業をPowerShellで行うようにしてみたが、今のところ問題は発生していない。
個人的には、ドライブの機能に注目している。ディスクアクセスに用いるドライブレターのような識別子を用いて、様々なデータへのアクセスを共通のコマンドで行えるようにした仕組みだ。例えば、カレントディレクトリ以下のファイル/ディレクトリの一覧はGet-ChildItem
コマンドレットで取得出来るが、Envという名のドライブへ移動した後なら同じ方法で環境変数の一覧を取得出来る。この仕組みはコマンドラインシェル以外にも応用が利きそうだ。エクスプローラのようなファイラ風のインタフェイスを備えたソフトから様々なデータにアクセスしたり。
2013年04月25日
Greasemonkeyの@grantメタデータの意義がよく分からない
amazon-bookmeter-link-adder.user.js ver1.01.20130425を作る時に、「@grant付けりーよー」とお猿さんに怒られたので、"@grant - GreaseSpot Wiki"を読んでみたが、イマイチこのメタデータの意義が分からない。
どうもセキュリティ関係の機構のようだが、"If a script does not specify any @grant values, Greasemonkey will attempt to auto-detect the right settings.
"と書かれているし、自動判定するのに要るんだろうかこれ。
- 怒られた
- しまった、キャプチャ取り忘れた。
2013年04月17日
TB: メンテナンスのお知らせ(2013年 4月17日実施)
メンテナンスのお知らせ(2013年 4月17日実施):Seesaaからのお知らせ
下記期間にメンテナンスを実施いたします。
(略)
- 期間
2013年 4月17日(水) 午前1時 から 午前6時 までを予定
メンテナンス終了時刻は、作業状況によって前後する場合がございます。
- 範囲
(略)
- Seesaaブログで作成されたブログへのコメント投稿・トラックバック送信
とのことなので、よろしくお願いします。
2013年04月16日
Windowsの環境変数の仕様についてメモ
2013年03月13日
TB: メンテナンスのお知らせ(2013年 3月13日実施):Seesaaからのお知らせ
メンテナンスのお知らせ(2013年 3月13日実施):Seesaaからのお知らせ
下記期間にメンテナンスを実施いたします。
((略))
期間
2013年 3月13日(水) 午前1時 から 午前6時 までを予定
*メンテナンス終了時刻は、作業状況によって前後する場合がございます。
範囲
((略))
- Seesaaブログで作成されたブログへのコメント投稿・トラックバック送信*2
((略))
- *2
- ユーザー様が作成されたブログは、メンテナンス期間中も閲覧出来る状態となっております(表示されづらい時間帯が発生する可能性はございます)。
2013年02月11日
TB: check_xxx がなんでダメなのか
check_xxx がなんでダメなのか - Yamashiro0217の日記
"check_xxx"みたいなメソッド名は避けようという意見には賛成。
だけど、流石にそれは例が悪い。
はてブのコメントでid:r-westが指摘しているように、いろいろな問題を詰め込んでしまってるから、「なぜその命名が拙いのか」という本題がかすんでしまっている印象。
"check_xxx の理由最初のだけ
"ならば、それに絞って書くべき。例え、"check_xxx 書くやつ、絶対他のこともそのメソッドでやるんだ
"としても。
以下、"check_xxx がなんでダメなのか
"を自分流に解説し直してみる。
元記事に則って、"check_user
"というメソッド名を例に説明する。
元記事のコードは……Perl? PHP? どっちにしろ忘却の彼方なので、以下Cのコードという事で。
例えば、以下のコード片、一体何をやっているのだろうか?
enum User_Kind {
USER_KIND_UNKNOWN,
USER_KIND_NORMAL,
USER_KIND_SUPER,
USER_KIND_ADMINISTRATOR
};
struct User {
char *name;
unsigned int age;
enum User_Kind kind;
} user;
/*
* なんかいろいろ
* ながったるい処理が
* 在ったり無かったり
*/
if(check_user(&user)) {
/*
* なんかいろいろ
* ながったるい処理が
* 在ったり無かったり
*/
// (1)
} else {
/*
* なんかいろいろ
* ながったるい処理が
* 在ったり無かったり
*/
}
うん、User
型オブジェクトの「何か」をチェックして、それで処理を切り分けている……でも、何をチェックしてるの?
パッと思いつくのは次の2つか。
- userの各メンバが「正しい形式に基づいているか」をチェックする。
(nameに使われている文字種や最大長、ageの値が想定内の範囲か、kindの値が不正ではないか、等) - userの各メンバに設定した値に合致するユーザーが居るかどうかを(DB等から)チェックする。
他にも考えられる処理があるかも知れない。
仮に(1)の位置に"removeUser(&user)
"とでも書かれていれば、後者の意味だったのだろうと予想(あくまで予想)出来るけれど、そこまで読み進めないと意味が読み取れないというのは、どうよ。可読性高いだろうか?
更に、1つだけならばまだしも二重三重と"check_xxx
"な条件分岐がネストされていたらと考えたら……
え? 定義元を読めばいいじゃんって?
確かに定義元を読めばその関数が何やってるのかは分かる。理屈の上では。
でもさ、その定義元(この例の場合では"check_user
")内に、更に"check_xxx"が在ったら? その定義も読むの? 更に更に"check_xxx"が在ったら? そうすると、どんどん読む必要が有る場所が増えていくよ?
で、読み終わって何やるメソッドか把握出来たら元の場所に戻って続きを……あれ?元の場所って何処だっけ?
// (各関数プロトタイプは省略)
// 略
if(check_user(&user)) { // 今読んでいる場所
// 略
}
// 略
_Bool check_user(const User *user) {
// 略
check_puyo(user);
// 略
}
Something check_puyo(const User *user) {
// 略
check_piyo(something);
// 略
}
Something check_piyo(const Something something) {
// 略
check_huga(something);
// 略
}
Something check_huga(const Something something) {
// 略
check_hoge(something);
// 略
}
Something check_hoge(const Something something) {
// 略
// ここまで読んで、やっとcheck_userが何やってたか分かる
}
え? コメント書けばいいじゃんって?
// 各メンバと同じ値を持つユーザーデータが有るか調べる
if(check_user(&user)) {
// 以下略
それってつまりは、以下の「明らかな事をわざわざコメントに書く」のと一緒だよね。
// fooが0未満の時
if(foo < 0) {
// 以下略
明らかに無駄。
そんな無駄なコメント書くぐらいならば、分かり易い名前付けようよ、と。
if(exists_user(&user)) {
// 以下略
これならば、「ユーザーの何について調べたいのか」は自明だよね(もっと良い名前はあるかも知れないけれど)。
2013年02月06日
GVimの起動時には幾つかの関数が使用出来ない
ここで言う"起動時"というのは、GVim起動直後の.vimrc処理時で、多分、"has('vim_starting')==1
"な時の事。
なお、GVim――つまりGUI用のVimでの話であって、コンソールで使う普通の(?)Vimでは問題ない。
NOTE: This function must not be used in a startup file, for
the versions that only run in GUI mode (e.g., the Win32 GUI).
しかしどうもinput()
だけの話じゃ無いようで、以下の関数が使えなかった。
input()
inputdialog()
inputlist()
confirm()
ユーザーに何か問い合わせる系統かな……そういう関数って他にも在る?
inputで始まる関数群はまともに動かない(空文字列とか0が帰ってきている模様)だけだけど、confirm()
が曲者で、Linux(Crunchbang)だとGVimの起動さえしない。
因みにWindows XPだと、第1引数と第2引数を改行で連結した内容がダイアログボックスで表示された。例えば、
call confirm('prompt', "Yes\nNo")
とだけ書いたファイル(%HOMEDRIVE%%HOMEPATH%\test.vim)を用意して、以下のように実行すると、
gvim -u "%HOMEDRIVE%%HOMEPATH%\test.vim" -U NONE
以下のダイアログボックスが表示される。
:autocmd
にするとよさげ。やや意味合いが変わってくるけれど、影響は無いんじゃないかなぁ?
autocmd VimEnter * call confirm('prompt', "Yes\nNo")
どうも、--cmd
オプションで使った時も同様の問題が発生する模様(あまりきちんと調べていない)。
バージョン7.3で確認。