【最強CUI】PowerShell -Part 2 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
と思って検証したらマジじゃねーかバーロー v2では使えないけどcat -raw|convertfrom-csvなら無視されなくなるから、#がCSVコメントとして無視されてるのではなくて、#をコメント行相当のオブジェクトとして返しているGet-Content側がタチ悪いという話じゃないだろうか PCに入ってるPowerShellのバージョンを簡単に切り替える方法はないのでしょうか? 作成したスクリプトがバージョン2でも3でも動くか等の検証を行いたいのですが? ISEがインテリセンス使ったら落ちてたのが KB4100403で修正されたらしい(未確認) エクセルに書き込む時、例えば for(i=1; -le 1000;i++){ sheet.cells.item(i,1)=i*5 } こんな感じにすると非常に動作が遅いのですがもっと高速にする方法はあるでしょうか。 なおvbaでは、 for i=1 to 1000 arr(i,1)=i*5 next と配列に入れておいてから、 oSheet.Range(oSheet.Cells(1, 1), oSheet.Cells(UBound(arr, 1), UBound(arr, 2))) = arr と一括で書き込むと速いのですが、PSでもこのような書き方はあるでしょうか。 >>769 速いかは知らんけどそれと同じようにするならこんな感じかね $n = 1000 $arr = New-Object "object[,]" $n,1 1..$n | foreach { $arr[($_-1),0] = [int]$_*5 } $sheet.Range($sheet.Cells.Item(1, 1), $sheet.Cells.Item($n, 1)) = $arr >>770 ありがとうございます。多次元配列を使えばよいのですね。 webで調べると多次元配列と多段階配列(ジャグ配列)がごっちゃになってるサイトもあって混乱していましたが、770さんの簡潔な記述をみて理解出来ました。 PowershellからExcelのユーザフォーム(コマンドボタン)を非表示かクリックできないようにしたいのですが、いくつか試してもうまく設定できませんでした。 ご存知の方がいたら、ご教示いただければ。 >>773 別のインスタンスからフォームを操作するってこと? 参考にVBAだとどうやるの? 以下で動くことは確認しましたが、できたらPowershellだけで完結したいです。 $excel = New-Object -ComObject Excel.Application; $book = $excel.Workbooks.Open('〜ファイル名〜'); $num1 = $excel.Worksheets.count ; $array = @() ; for ( $i1 = 1 ; $i1 -le $num1 ; $i1++ ){ ; if ( $excel.Worksheets.Item($i1).name.substring( 0, 4 ) -eq 'xxx_' ) { ; $array += $excel.Worksheets.Item($i1).name ; } ; } ; for( $i2=0; $i2 -lt $array.count; $i2++){ ; $shtname = $array[$array.count-$i2-1] ; $MDB_index = $excel.Worksheets.Item('MDB').index ; $excel.Worksheets.Item($shtname).move( $excel.Worksheets.Item( $MDB_index ) ) ; $excel.Worksheets.Item('MDB').move( $excel.Worksheets.Item( $shtname ) ) ; $excel.Worksheets.Item($shtname).name = 'yy_' + $shtname.substring( 4, $shtname.length - 4 ) ; } ; $excel.run("Unable") * VBAのUnableの中身 ; Sub Unable() Dim SHTNAME As String Dim NUMBER As Integer Dim I1 As Integer NUMBER = ThisWorkbook.Worksheets.Count For I1 = 1 To NUMBER SHTNAME = ThisWorkbook.Worksheets(I1).Name If Mid(SHTNAME, 1, 3) = "yy_" Then ThisWorkbook.Worksheets(I1).CBT1.Enabled = False End If Next End Sub >>776 xxx_のシートをMDBの後ろに並べたいってことでいいんかね? $book.Sheets[$book.Sheets.Count..1] | where { $_.name -like "xxx_*" } | foreach { $_.move([Reflection.Missing]::Value, $book.Sheets("MDB")) $_.name = $_.name -replace "^xxx_","yy_" $_.OLEObjects("CBT1").Enabled = $false } >>778 VBAに依存せず実行できました。感謝。 windows10ですが Get-ItemPropertyでLastWriteTimeを見てみると エクスプローラで表示される更新日時と異なるファイルが有りました 更新日時の方が作成日時より前の日付になってるので おそらく LastWriteTimeの方が正しい日付だと思います これを訂正するためにPSからエクスプローラの更新日付を取得したいのですが エクスプローラの更新日時がどこから来ているものかさっぱりわかりません いくつかファイルを調べてみると、更新日時とLastWriteTimeの差が一週間離れているのも有るので タイムゾーンの問題とは考えにくいです よく見ると、作成日時もCreationTimeと10日くらいのずれが有りましたw エクスプローラが詳細プロパティ以外の日付を参照してる意味が分かりません windowsの強制メジャーアップデートで何度かクラッシュした影響でファイルが壊れてるのかも 「書き込みがあったら反応しよう」と思ってる人がたくさんいるからかな? わしはね、ローカルの小物guiでps始めよう思ってたらhtaというものを発見してしまったんじゃ 若者が「HTAって使えるんじゃね?」と思ってしまうのは仕方がない。 オッサン〜ジジイが「HTAを発見した」つったら「今まで何して生きてきたの?」としか言いようがない。 Windowsでのローカルの小物GUIは、今、滅亡の危機ですらある。 WordやExcelを使った自動化すら、今後もできるかどうか怪しい。 HTA軽くていいよね機能追加も楽だし ランチャーにしてる ローカル実行できるスクリプトで動くGUIアプリに決まってるだろ。 Excel や Access の VBA がその代表格。 COM がベースだから切られる方向なのは分かる。 でも代替できるものがない。 いっとき PowerShell+WPF が期待を担ったが… ・呼ばれる側のアプリにコマンドレットの実装が必要 ・.NET ごとオープンソースの世界に行ってしまって Windows そのものが切られそう ・そういうのは C# で書いて配れ、と明示的に言ってくれた方がまだ楽。 が、MS はダンマリを決め込んでいるんだよなぁ… >>793 >COM がベースだから切られる方向なのは分かる。 >でも代替できるものがない。 よく調べてないんだけどVisual Studio Tools for Officeとかはダメ? powershell入ってないXP以下で使えるんすよ 判ってくださいよ とりあえず、PowerShellが「最強CUI」とかいう寝言は取り下げた方がいい。誤解を招く。 >>797 誤解してるのはお前だけだからお前がどっかに行けば解決 >>798-800 管理目的なら最強だろう。確かに。 が、それ以外の目的にはおおよそ優しくない。てゆーか元の開発陣がそう言ってる(管理目的、API指向)。 OSSになったから 6以降も(3でもやったけど…)破壊的な仕様変更をゴリゴリやりそう。 特に PowerShell Desktop は今後バージョンアップは無さげだから、管理系以外の Win系のユーザーは手を出す理由がない。 Win系ですら 「引き継ぎを考えたら VBScript で書いておこうか…」てなる。 WPF は死亡寸前だし。 Winユーザーはバッチや VBScript の後継としての役目を捨てようとしている PowerShell に文句を言う筋合いはあると思うがね。 純粋な対話型CUI の最強は bash系列だし。 何言ってんの?? どこがどう最強なのか言って欲しいわ。 特に、Office系の自動化なんて COMオブジェクトに頼らないと無理だろ。 PowerShell で書くといちいち Excel のセルですらリソース開放が必要でクソ面倒。 Set objExcel = Nothing とサクッと書けるほうがいいに決まっている。 PowerShell は万能じゃねーんだよ!馬鹿ども。 C#erだから.NETライブラリがそのまま使えるPowerShell好きだわ >>804 最近作ったのはCのヘッダーからC#ラッパー生成するやつ VBAスレに来てるPowerShellゴミクズ荒し何なの? PowerShellの工夫はより良くするための工夫でVBAの工夫は欠陥を補う工夫って、どのロで言うんだろうね。 VBAだとソース管理出来ないというから、ソース抜き出してソース管理ツールに渡すのはダメという意味なんだろうけど、その割にPowerShellだとVisualStudioと連携できるとか言い出すダブスタ。 PowerShellでC#コンパイル出来るとか、バカ丸出し。 csc使うんだったら何だって出来るだろう。 コイツがムカつくのはそういう工夫を全て否定する所。 それを否定するならPowerShellだってゴミクズだろう。 そういう工夫こそが大事なのに。 スクリプトなんて適材適所で何使ったっていい 他人がなんかいちゃもん付けてきたら、 「こいつ初心者で一時的に心酔してバカ発言してるんだな、 あと数ヶ月もすればこのときのことを思い出して恥ずかしさにそこらへんを転げまわるんだろうな」 程度に気の毒がってりゃいいさ エクセルなんて要らん工夫して紙と電卓を使いこなせば事務作業はできる 会社に支給されたパソコンを目の前置いて、こう主張するおじいさんが居たらどう思う? 馬鹿だねーエクセルなんて簡単なのになんで電卓使うの? 社員ならエクセル使っていいのになんで? そう思わないかな? もし思わないなら根本的に感覚がズレてるので同意を得るのは難しいと思うよ つかわざわざこっちにきて何がしたいん? そいつに言えばいいやん お前もゴミだろう >>811 ことごとく論破されたので逃げてきたんだろう >>811 VBAのスレが荒れるのが嫌だからでしょ 考えたらわかるじゃんw 脳みそあるの? >>812 PowerShellユーザが迷惑かけてるんだから スレとしての責任が問われてる 散々論破しているのに最後まで居座られて迷惑してスレが終わったからだよ。 そしてPowerShellの立場はExcelと被るわけでどっちも適材適所だろ。 その場に合ったのを使えば良いんだ。 奴は自分がPowerShellを貶めてるのに気付いて無い。 読んできた Rubyキチが紛れてるのが無理矢理すぎて笑える >>816 馬鹿野郎、てめんとこの人間が迷惑かけてんだから うちの者がご迷惑おかけして申し訳ありません と謝罪するのが筋だろうが ほんとPowerShellは他人に迷惑かけてバッカやな ほんまクズやな、PowerShellのせいやろな >>822 ぼくは何も行動してないからね、完全に無害だけど スレ立てしちゃった人がいるんだよ、ぼくはその人を知ってるんだ >>816 こいつです、こいつVBAのスレを立てやがりました 自分がどれだけ悪いことをしたのかについてもわかってないと思います 頭の悪い人っているんだなって思いました 自発的に間違った行動をとる組織にとってのガン細胞が確認されました なんでVBAのスレ立ててもうたんや 何してくれてんのや PowerShellユーザが言い訳できないレベルで 全面的に悪いことになってまうやろ なんでや!?なんでやねん!なんでスレ立ててもうたんや!! なんでもっと冷静に行動でけへんねん スレ立てたら済むと思ったんか? なに考えてんねん なんでこんな前例を作ってしまったんや この過ちはPowerShellの後世に禍根を残すで >>831 大造じいさん「ぐぅぅ、わしはもうだめや・・・」 さて、残念なことが起きました この中にVBAのスレを立てた人がいます 正直に手を挙げてください いくら何でもこれはないわ。 どっちがよりクズかって言ったら断然VBA住人だろう。 PowerShell -Part 3 http://mevius.5ch.net/test/read.cgi/tech/1532236932/ >>839 ずいぶん可愛そうな環境で育ったんだな。同情するよ、ごめんな。 >>808 > PowerShellでC#コンパイル出来るとか、バカ丸出し。 残念ながらそんな昭和脳レベルの話じゃないんだな w http://yomon.hatenablog.com/entry/2013/06/05/PowerShell スクリプト内でC%23コードを書いて使う Powershellのコマンドを使ってあるEXEを管理者権限で起動することって出来ないでしょうか? いちいちEXEのショートカットを作って「管理者として実行」にチェックするのが面倒なので・・・ あ、OSはWin7です。 start hoge.exe -Verb runas >>842 あんまり、荒らすつもりは無いけどそれはダメダメだね。 というか、その昔俺もその手法使ってたし。 俺の書いたPS1ファイルのタイムスタンプを見ると2011年だからその記事より前だな。 あのね、何でC#のソースを動かさなきゃならんの? そういう場面が有るとすればPowerShellだけで出来ないことをしようとする場合だろ。 つまり工夫で乗りきろうとしている場合なんだからVBAのスレを荒らしてた奴風に言わせればC#のソースを書かなきゃならん時点でPowerShellはゴミってことになるのよ。 VBA内でC#のクラス定義してそのままVBA内で使えるようになってから出直してこい 何をするにも不合理に手間がかかるからVBAは糞だって言ってんだよ なんで既存のソース活用するのにcscだの別プロセスだの大げさなことしないといかんの? .NETがあるのになんで態々COMだのwinAPIだの直で触らなあかんの? っていう人間なので問題なしです >>846 > そういう場面が有るとすればPowerShellだけで出来ないことをしようとする場合だろ。 バカなの? ・C#のほうが楽に書ける ・既存のコードが流用できる とかあるだろ >>847 PowerShellだって不合理じゃねーか。 お前は都合の良いところばかり言う。 Excelブック1ファイルで完結できるようになってから出直しな。 >>850 同じことだ。 欠点を工夫で乗りきっているわけだから。 はるほど、ExcelVBAスレで暴れてた奴今度はこっちに来てたのか… >>851 どこが同じなんだよ w > 出来ないことをしようとする ↕ > 楽に書ける > 流用できる >>854 出来ないことをしようとする。 ←C#のコ―ドをそのままC#でコンパイルして、出来たプログラムを動かす。 出来ないことをしようとする。 ←コンパイル済みのプログラムを高速に動かす。 出来ないことをしようとする。 ←VisualStudioでGUIのデザインをする。 出来ないことをしようとする。 ←面倒なことをPowerShell単体で実現する。 な、一緒だろ。 もう引っ込みつかなくなって意味不明なことを語りだしたか w PoshもVBAも 同じMS製品なんだから ケンカすんなよ 日本語が通じないのはお互い様だろ。 C#に比較して楽に書けて無いだろ。 つまりC#を元に考えればゴミということになる。 別途VSCodeとかを入れるのは面倒じゃ無いのか? C#のコード部品にもインテリセンスが効くのか? 楽だとすればそれはC#のことでPowerShellは文字列変数にコード入れなきゃならん。 そして文字列をC#のコードとして動かす為にもAdd-Type呼び出すなどと面倒なことをしなきゃならん。 >>860 まったくもってその通りで C#>PowerSell だよ もっと書くと C# > PowerSell >>>>>>>>> VBA だけど なんで唐突にC#と比べはじめちゃったの? 向こうでもVSCodeやらIDE入れたら〜ってレスしてるやついるけどさ VBAを主に使うのは事務屋 ↓ 事務の職場は(開発系と違って)外部ソフトの導入を渋られる所が多い ↓ 結局Windows付属の ・VBA ・VBS ・cmd ・PowerShell しか使えない ↓ エクセルにあまり関わらない処理はPowerShellでやってもいいんじゃね って感じだと思うの (というか、現にウチがこれ) この、VBA(VB6)かPowerShell「しか」手段がない前提で行けば、 C#のソース読み込むとか多少歪んだ使い方だとしてもVBAよりPowerShellを使いたくなる時があるのは理解できるだろ? もちろんVBAもバリバリ使ってるけどな なんでどちらかだけしか使う価値がない!!!みたいな話になってんだろ ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる