【追記】この問題は下記の記事で解決されています
概要
下記２つの問題が出た影響でWindowsでのActivePerlを利用した開発は絶望的だったのだが解決できたので報告。
http://qiita.com/umiai/items/7564fa745b205171268a
http://qiita.com/umiai/items/ffb0de687e4383b823c4
上記の原因
原因自体は不明、やはりアクセス権絡みだとは思うが・・・。
誰が見ても「それは無い」と言われそうだけれど何も書かないのもアレなので一応記載してみる。
(あまり突っ込まないでほしい)
Windowsにcygwinを入れるとcygwin管理のアクセス権とOS管理のアクセス権が競合するような動作になってしまった。
OS管理のアクセス権を変更してもうまく動作しないが、cygwinのbinにあるchmodでアクセス権を変更すれば上手く動作するようになる。
こんなことは有り得ないなんて知っているが今回この問題を解決するうえで一番重要なのがここで、
事も有ろうか git clone したディレクトリに対して cygwinでchmod -R 777 * するというのが
この問題の解決方法なのだから正直もうさっぱりだし多分泥沼だからもう考えたくもない・・・。
解決方法
既にいっちゃってるけど git clone したディレクトリに対して cygwinでchmod -R 777 * すればいい。
共同開発の場合に開発環境を構築するなら次のようなバッチを用意すれば良いだろう。
rem git setup
mkdir trunk
cd trunk
git clone AAA.git
git clone BBB.git
git clone CCC.git
chmod -R 777 *
その他の原因と思われし事象
cygwinを入れた後にActivePerlを入れると環境変数のPathにcygwin側のperl.exeとActivePerl側のperl.exeが存在することになる。
さてこの状態でコマンドプロンプトにperlと入力したらどちらが使われるのだろう？
というところがミソで割とこっちの問題な気がしなくも無い。
で出ていた問題の１つにパスがUNIX形式に変換される問題が出ていた。
ActivePerl側のperl.exeはWin環境に合わせて作られているので多分こっちならそんな変換はしないはずだが、
シェルを叩く都合があるcygwin側のperl.exeの場合は変換するような仕様になっていても決して不思議ではない。
このあたりに気づいたのはperlを諦めてrubyを入れた後ruby -vしたらバージョンが古く、
その叩かれたruby.exeがcygwinのものであった為にこの問題に気づいた。
アクセス権や上記のperlの問題などが絡んで発生していたのかもしれない。
環境変数弄ったほうが良さそうだけどcygwin側で動作しなくなるのもいやっちゃ嫌なので
確実な対応としては叩くperlは絶対パスで指定するといったところだろうか。
ActivePerlでx64のデフォルトなら
C:\Perl64\bin\perl.exe AAAAA.pl
かな。まぁどちらにしても微妙だけど。