【追記】この問題は下記の記事で解決されています
概要
今までこの組み合わせで開発を進めてきて特に問題無かったのだが、
別のPCからgit cloneして問題無く動作するのかを確認しようと思ったら
の問題と同時に様々な問題が発生し結構絶望的な事が判ったのでそれに関しての共有。
とりあえず出た問題一覧
- git cloneしたバッチファイルからperlスクリプトを叩くとパスがUNIX形式に変換される
- perlスクリプトがシェル上で動作している扱いになりコマンドプロンプトのコマンドが実行できない
- pushしたPCではperlスクリプトがコマンドプロンプト上での動作扱いのため統一を取る事が不可能
- 上記の問題の影響でVisual Studioからバッチファイルを通してperlスクリプトを叩いてる箇所が全滅
git cloneしたバッチファイルからperlスクリプトを叩くとパスがUNIX形式に変換される
理由は不明だがcygwinをインストールしているとperlスクリプトが行う各種処理がシェル上(cygwin上)での動作扱いになっているように見える。
実際に確認できたわけでは無いが少なくとも\を/とした際にでるcygwin特有のwarningが表示されたあたりcygwin上での動作になっていると予想した。
UNIX形式のパスに変換されてるというのは、例えばperlスクリプトに引数で
C:\SVN\repository
というパスを渡したとする。
しかしperlスクリプト上だと次のように表示されてしっまった。
/c/SVN/repository
この/c/というのはUNIX形式のパスに変換されてしまっているからで、当然Windows上ではまともに動作しない。
一応ActivePerl側で動作が許容されてる気がしないでもないけどsystem関数で外部アプリケーションをキックしたりしてると死ぬ。
例えば圧縮用アプリケーションにパスを渡す際に
system "arcive.exe \$targetPath"
みたいなことしてると$targetPathがUNIX形式のパスなので死ぬ。
perlスクリプトがシェル上で動作している扱いになりコマンドプロンプトのコマンドが実行できない
シェル上での動作扱いになってるので例えば次のコマンドが実行できない。
# (perl側のFileパッケージで提供されてるmove使えという話は一先ずスルーして・・・)
system "move \$src, \$dst"
片っ端からsystem使ってるところを全部置き換えれば良いのだがそうもいかない場合もあるはずなので現実的ではない。
pushしたPCではperlスクリプトがコマンドプロンプト上での動作扱いのため統一を取る事が不可能
pushしたPC側はperlスクリプトがコマンドプロンプト上での動作扱いなので
上述されてる
# (perl側のFileパッケージで提供されてるmove使えという話は一先ずスルーして・・・)
system "move \$src, \$dst"
のコマンドがまともに動作してしまう。
というより、むしろこれをシェル上での動作扱いでのPCで動くようにしたバージョンが動かない。
割と詰んでる。
上記の問題の影響でVisual Studioからバッチファイルを通してperlスクリプトを叩いてる箇所が全滅
Visual Studioのビルド後イベントをバッチファイルからPerlスクリプト呼び出してやってたので全滅した。
現状手詰まりでどうしようか悩んでる・・・
問題は解決するのか？
(Windowsでgit cloneするとアクセス権周りの情報が破壊される問題について)
http://qiita.com/umiai/items/7564fa745b205171268a
で色々と試したけどどうしてもシェル上での動作扱いになるのを防ぐためには「管理者として実行」するしかない。
Visual Studioや各種バッチファイルを毎回管理者として実行するのは面倒過ぎる・・・
唯一あるとすればシェル上での動作扱いで統一した後、pushしたPC側では再度リポジトリをgit cloneしてもらう。
スクリプトファイルはあんまり追加する事は無いだろうからそこまで手間ではないはず。
ただかなり微妙だ・・・