アカウント名:
パスワード:
IF EXIST "%FILENAMEVAR%" del /f /s /q "%FILENAMEVAR%" > NUL 2>&1みたいにすればだいじょうぶなのでは?
いやまぁ、原因がわかってればそうなんですが、今までの経験上(bash, perl, pythonなど)、空文字指定でファイルが削除されるなんて思ってもいなかったわけで。
ヘルプ処理でメインコードが実行されていなくても、delさんは華麗にスルーしてくれる、と信じて疑わなかったわけです。だからこそ強制削除&出力廃棄していたんで....
まあ、なんて言うか、いまどきcmd.exeでもなかろうよ。PowerShellを使うべき場面だろうね。条件が許さなければ仕方ないけど。
おまえはなにを言っているんだ?Remove-Itemに空文字食わせたって、エラーで死ぬだけじゃねーか?
そもそも他の処理系と同じようにスルーしてりゃ問題ないのに勝手に変な解釈して、いつもいつも大きなお世話をしてくれるMSの処理系が問題の根本なんだよCMDからPowerShellに代えようがそれは何ひとつ変わらない
# MSの処理系はAPIひとつに至るまで未定義の動作が多すぎる# しかも「未定義=デフォルト」じゃないから、ある日突然MSがデフォルトの動作を決めて# それまで「未定義=デフォルト」だと仮定していた全てに問題が起きる# C/C++のようにそれが未定義ならちゃんと、「 ~な時の動作は未定義である」と書いておいてくれなきゃ困るわ >>>>>MS
Remove-Itemに空文字食わせたって、エラーで死ぬだけじゃねーか?
それでいいじゃない。少なくとも、今回のような悲劇は無かっただろ?
そもそも他の処理系と同じようにスルーしてりゃ問題ないのに
それは思想の差。すべての処理系が同じ思想で設計される必要は無い。君の思想だけが正しいわけでもない。
CMDからPowerShellに代えようがそれは何ひとつ変わらない
それはウソ。少なくとも今回のような場合の結果は違うんだから。
いまどきCMD.exeもVBScriptもJScriptも使おうとは思わないけど、PowerShellはそう悪くないよ。配列指向を理解するのに時間はかかるかも知れないけど。例えば、今回のようなケースであれば、次を参考にコーディングすればいいよ。
$ $file = 'a.txt'$ '' | Set-Content $file$ dir ディレクトリ: C:\TMP Mode LastWriteTime Length Name---- ------------- ------ -----a--- 2012/04/30 16:44 2 a.txt $ @() | Remove-Item$ dir ディレクトリ: C:\TMP Mode LastWriteTime Length Name---- ------------- ------ -----a--- 2012/04/30 16:44 2 a.txt $ @($file) | Remove-Item$ dir$
これなら、空列を渡してもエラーにはならない。まあ、空文字列を渡しちゃうとエラーになるけどね。
要するに、これが思想の差。他の処理系とは違うけど、悪かぁないだろ? こういう処理系があってもいいんじゃない? いろんなものがあった方が、世の中楽しいだろ?
あ、もちろんPowerShellにもエラー処理構文は準備されているから、それを使ってもいいと思うよ。
こう言う方法もあるよ。
$ Remove-Item ''Remove-Item : 引数が空の文字列であるため、パラメーター 'Path' にバインドできません。<<略>>$ $ErrorActionPreference = 'SilentlyContinue'$ Remove-Item ''$
しかし、こんな風にはできない。
$ Remove-Item '' -ErrorAction SilentlyContinueRemove-Item : 引数が空の文字列であるため、パラメーター 'Path' にバインドできません。<<略>>$
まあ、これが良い設計か、って言うと疑問だけどね。
他人に提供するものだと素のOS標準で使えるものっていう条件がついたりするんですよね。自分でしか使わないなら、間違いなくbashで組むけど。
他人に提供するものだと素のOS標準で使えるものっていう条件がついたりするんですよね。
そうだね。元の話はXPだから、標準搭載ではないね。でも、Windows 7・Windows Server 2008(無印)以降には標準搭載だよ。
自分でしか使わないなら、間違いなくbashで組むけど。
Bashは悪くない。Ryo.F自身、手元のマシンにはCygwinを入れている。だけど、.Netとかにはアクセスできないだろ? 今後のことも考えれば、PowerShellの方がいいと思うよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
こんなふうにすれば (スコア:1)
IF EXIST "%FILENAMEVAR%" del /f /s /q "%FILENAMEVAR%" > NUL 2>&1
みたいにすればだいじょうぶなのでは?
Re: (スコア:1)
いやまぁ、原因がわかってればそうなんですが、今までの経験上(bash, perl, pythonなど)、空文字指定でファイルが削除されるなんて思ってもいなかったわけで。
ヘルプ処理でメインコードが実行されていなくても、delさんは華麗にスルーしてくれる、と信じて疑わなかったわけです。だからこそ強制削除&出力廃棄していたんで....
ん? 俺、今何か言った?
Re:こんなふうにすれば (スコア:1)
まあ、なんて言うか、いまどきcmd.exeでもなかろうよ。PowerShellを使うべき場面だろうね。条件が許さなければ仕方ないけど。
Re: (スコア:0)
まあ、なんて言うか、いまどきcmd.exeでもなかろうよ。PowerShellを使うべき場面だろうね。条件が許さなければ仕方ないけど。
おまえはなにを言っているんだ?
Remove-Itemに空文字食わせたって、エラーで死ぬだけじゃねーか?
そもそも他の処理系と同じようにスルーしてりゃ問題ないのに
勝手に変な解釈して、いつもいつも大きなお世話をしてくれるMSの処理系が問題の根本なんだよ
CMDからPowerShellに代えようがそれは何ひとつ変わらない
# MSの処理系はAPIひとつに至るまで未定義の動作が多すぎる
# しかも「未定義=デフォルト」じゃないから、ある日突然MSがデフォルトの動作を決めて
# それまで「未定義=デフォルト」だと仮定していた全てに問題が起きる
# C/C++のようにそれが未定義ならちゃんと、「 ~な時の動作は未定義である」と書いておいてくれなきゃ困るわ >>>>>MS
Re:こんなふうにすれば (スコア:1)
Remove-Itemに空文字食わせたって、エラーで死ぬだけじゃねーか?
それでいいじゃない。少なくとも、今回のような悲劇は無かっただろ?
そもそも他の処理系と同じようにスルーしてりゃ問題ないのに
それは思想の差。すべての処理系が同じ思想で設計される必要は無い。君の思想だけが正しいわけでもない。
CMDからPowerShellに代えようがそれは何ひとつ変わらない
それはウソ。少なくとも今回のような場合の結果は違うんだから。
いまどきCMD.exeもVBScriptもJScriptも使おうとは思わないけど、PowerShellはそう悪くないよ。配列指向を理解するのに時間はかかるかも知れないけど。
例えば、今回のようなケースであれば、次を参考にコーディングすればいいよ。
これなら、空列を渡してもエラーにはならない。まあ、空文字列を渡しちゃうとエラーになるけどね。
要するに、これが思想の差。他の処理系とは違うけど、悪かぁないだろ? こういう処理系があってもいいんじゃない? いろんなものがあった方が、世の中楽しいだろ?
あ、もちろんPowerShellにもエラー処理構文は準備されているから、それを使ってもいいと思うよ。
Re:こんなふうにすれば (スコア:1)
こう言う方法もあるよ。
しかし、こんな風にはできない。
まあ、これが良い設計か、って言うと疑問だけどね。
Re: (スコア:0)
まあ、なんて言うか、いまどきcmd.exeでもなかろうよ。PowerShellを使うべき場面だろうね。条件が許さなければ仕方ないけど。
他人に提供するものだと素のOS標準で使えるものっていう条件がついたりするんですよね。
自分でしか使わないなら、間違いなくbashで組むけど。
Re:こんなふうにすれば (スコア:1)
他人に提供するものだと素のOS標準で使えるものっていう条件がついたりするんですよね。
そうだね。元の話はXPだから、標準搭載ではないね。
でも、Windows 7・Windows Server 2008(無印)以降には標準搭載だよ。
自分でしか使わないなら、間違いなくbashで組むけど。
Bashは悪くない。Ryo.F自身、手元のマシンにはCygwinを入れている。
だけど、.Netとかにはアクセスできないだろ? 今後のことも考えれば、PowerShellの方がいいと思うよ。