[7466] コマンドラインからgrep処理について返信 削除
2011/11/17 (木) 10:05:10 あきら
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.106 Safari/535.2
サクラエディタで次ぎの流れで作業することは可能でしょうか?

コマンドラインからgrep処理を起動し、GUIを表示しない
 ↓
grep処理の結果をパイプラインに渡す
 ↓
サクラエディタプロセスを終了する。

つまりGnu Grepのように使いたい。


[7468] Re:コマンドラインからgrep処理について返信 削除
2011/11/18 (金) 06:55:19 syat
Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20100101 Firefox/9.0
▼ あきらさん
サクラエディタだとGUIは表示されますし、結果をパイプラインに渡すのもできないと思います。
Windowsには findstr というGrep風コマンドがあるのでそちらを調べたほうが良いかと…

人の手をはさんでよいなら以下のようにします。
コマンドラインから-GREPMODEなどのオプションでGrep起動
 ↓
Grep結果を"手動で"テキストファイルに保存
 ↓
サクラエディタを"手動で"終了
 ↓
コマンドラインから type コマンドで保存したテキストを表示



[7749] Re2:コマンドラインからgrep処理について返信 削除
2014/1/6 (月) 14:10:55 すなっくぱん
Opera/9.80 (Windows NT 6.1) Presto/2.12.388 Version/12.16
自分も結局手動で保存しているのですが、最近Ver2.0.5.0から2.1にしたところ、
デフォルトでの保存先がカレントではなくなってしまいました。
コマンドで保存先をカレントに指定してからGREPMODEで起動し即保存とやっていたので少し困っています。

どうやら下記修正の影響のようですので、
(Grep終了後Grep画面のフォルダを検索したフォルダに変更する(svn:2473 upatchid:269 Uchi) )
Grep時のデフォルト保存先をカレントにするコマンドラインオプションを追加したりはできないでしょうか。

findstrでは文字コード混在しているので化け化けになってしまいますし
エディタとして編集してから保存できるのはとても便利です。
尤もコマンドラインで直接ファイルに保存まで持っていければそれに越したことはないのですが…。


[7750] Re3:コマンドラインからgrep処理について返信 削除
2014/1/7 (火) 18:47:19 もか
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0
オプションを追加してみました。
https://sourceforge.net/p/sakura-editor/patchunicode/742/


[7768] Re4:コマンドラインからgrep処理について返信 削除
2014/1/28 (火) 19:05:15 すなっくぱん
Opera/9.80 (Windows NT 6.1) Presto/2.12.388 Version/12.16
オプション追加、2.1.1.0で確認できました。
ありがとうございました。


[8027] Re:コマンドラインからgrep処理について返信 削除
2015/4/22 (水) 15:56:24 すなっくぱん
Opera/9.80 (Windows NT 6.1) Presto/2.12.388 Version/12.17
Ver2.2.0.0にて実装して頂きとても感謝しています。

ただ、batとして組んで直接実行したものは正しく動くのですが、
タスクスケジューラに一日一回実行として時間指定登録したものが上手く動きません。
タスクを右クリック→実行した場合には正しく動作します。

プロセスを監視していると、
タスクスケジューラから呼ばれたcmdから呼ばれたプロセスとして
sakura.exeは起動している為、タスク設定とバッチ自体には問題はなさそうです。
正常なら数秒で終了するはずのsakuraがずっと残りっぱなしになっており、
リダイレクト先のtxtはロックがされているもののGrepヘッダなども何も出力されず真っ白となります。

電源オプションの「次の時間が経過後ハードディスクの電源を切る」が
影響しているのではと思い、この設定を無効にして試しましたが、
一日目は成功したものの二日目は以前同様失敗しました。

現在は「タスクトレイに常駐する」を設定していたことが影響していると想定し、
この設定を解除した状態をテストしようとしています。

イベントログとして、ID1530が出力されていますがタスク実行時間とずれており、関係があるか不明です。
http://blogs.technet.com/b/sharepoint_support/archive/2012/12/17/comexception-0x800703fa.aspx

環境はWin7 SP1 32bit Sakura Ver2.2.0.1です。


[8028] Re2:コマンドラインからgrep処理について返信 削除
2015/4/25 (土) 13:52:30 syat
Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36
▼ すなっくぱんさん

自分のところでタスクスケジューラを5分間隔で実行したところうまく動いたのでタスクスケジューラの問題ではないと思います。
タスクトレイ常駐はオンにしています。

失敗するときにパソコンがロック中とかスタンバイ状態とか発生条件がないでしょうか?



[8029] Re3:コマンドラインからgrep処理について返信 削除
2015/4/27 (月) 11:53:27 すなっくぱん
Opera/9.80 (Windows NT 6.1) Presto/2.12.388 Version/12.17
▼ syatさん
確認ありがとうございます。

動作時状況はログオフ中ですが、スリープ・スタンバイ・休止等はしておりません。電源オプションの時間設定も切ってあります。
タスクとしては管理者アカウントを設定し、ログオンしているかに関わらず実行にしています。
また、Grep実行前に同バッチ内で別ファイルへのECHOリダイレクト書き出し等はできているため、タスクの実行は正常です。
同一設定で成功と失敗の事例がある為、その際の条件の差異は前日起動したSakura-NOWINが起動しているかどうかくらいしか思い当りませんでした。

タスクトレイ常駐設定を解除してからは正常に動作しています。

バッチ内でのGrep実行コマンド
"サクラエディタパス" -GREPMODE -GKEY="検索文" -GFILE="*" -GFOLDER="検索フォルダ" -GCODE=99 -GOPT=PR2XU >"出力ファイル"
停止状況
出力先テキストは真っ白でファイルロックされている。


[8030] Re4:コマンドラインからgrep処理について返信 削除
2015/5/8 (金) 09:47:22 すなっくぱん
Opera/9.80 (Windows NT 6.1) Presto/2.12.388 Version/12.17
タスクトレイ常駐設定を解除した状態でも処理が停止しました。

バッチ内では以下のコマンドを検索文と出力ファイルを変えて複数回実行しているのですが
今回は一つ目は正常に実行されましたが二つ目が停止しました。
> "サクラエディタパス" -GREPMODE -GKEY="検索文" -GFILE="*" -GFOLDER="検索フォルダ" -GCODE=99 -GOPT=PR2XU >"出力ファイル"

つまり、バッチ、タスクスケジューラには問題がなく、
サクラエディタが何かしらの要因で停止しているようです。
ただ、たとえばエラーダイアログが出ているとしてもログオフ時実行なので確認できません。

停止していたプロセスの状態としては
svchost.exe-taskeng.exe-cmd.exe-sakura.exeで
sakura.exeはCPUを0.02%のまま変動せず、メモリは2.6M使用していました。
このsakura.exeをKILLしたところ、後続のGrep処理は正常に動作しました。
正常動作の際は、プロセスツリーが
svchost.exe-taskeng.exe-cmd.exe-sakura.exe-sakura.exe
というように起動していました。(sakura一つ目はGrepコマンド、二つ目はNOWINのようでした。すぐに処理が終わってしまうのであまり確認できませんでしたが)
このことから、NOWINのプロセスを起動する際に何かしら問題があるのかと思います。


[8031] Re5:コマンドラインからgrep処理について返信 削除
2015/5/8 (金) 21:11:09 anonymous
Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; Touch; MANMJS; rv:11.0) like Gecko
ログオフ時実行だとそれ以上プロセスを生成させてもらえない。

最初のプロセスがコントロールプロセスを生成しようとする

最初のプロセスがコントロールプロセスの失敗を検出する

エラー表示(ポップアップ)する

見えないポップアップでロック状態になる


[8032] Re6:コマンドラインからgrep処理について返信 削除
2015/5/12 (火) 14:55:08 すなっくぱん
Opera/9.80 (Windows NT 6.1) Presto/2.12.388 Version/12.17
▼ anonymousさん
情報ありがとうございます。

> ログオフ時実行だとそれ以上プロセスを生成させてもらえない。
というのはWindowsの仕様としてタスクスケジューラでの
ログオフ時実行ではプロセスの生成ができないということでしょうか。
自分でも調べてみましたがそういった情報は見つけられなかったのですが
可能でしたらURL等ご教示願えないでしょうか。

> 最初のプロセスがコントロールプロセスを生成しようとする
以降の部分はサクラエディタがそういう動きをするということですね。
プロセス生成の失敗が原因という事なのでそれを回避する方法を検討します。


[8033] Re7:コマンドラインからgrep処理について返信 削除
2015/5/12 (火) 20:26:09 anonymous
Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; Touch; MANMJS; rv:11.0) like Gecko
先の返信は1だと思って答えたのですが、ログオフ時っていうのは
1.ログオフするタイミングですか
2.ユーザが誰もログオンしていない状態ですか

1は経験的にタイミングによってできません。
2はセッションがないのでサクラが画面表示できずまともに動かないのではないでしょうか。



[8034] Re8:コマンドラインからgrep処理について返信 削除
2015/5/12 (火) 20:45:06 anonymous
Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; Touch; MANMJS; rv:11.0) like Gecko
セッションの話で思いついたのですが、
サクラエディタはコントロールプロセスの制御のためにセマフォ等を使ってます。
セッションがない場合にこのセマフォの範囲ってどうなるんでしたっけ。
詳しい方よろしくお願いします

個人的には、別のツール使うか、サクラエディタのGREP部分を切り出して専用のexe作ったほうが確実だと思います。



[8035] Re9:コマンドラインからgrep処理について返信 削除
2015/5/13 (水) 10:22:06 すなっくぱん
Opera/9.80 (Windows NT 6.1) Presto/2.12.388 Version/12.17
▼ anonymousさん
ログオフ時というのは2の方のことです。
タスクスケジューラに管理者アカウントで「ユーザーがログオンしているかどうかにかかわらず実行する」を設定したタスクを作成し、早朝のだれもログオンしていない時間帯に実行しています。
設定してから現在までのところ、9割がたは問題なく動いていますので「まともに動かない」という事はないと思いますが、稀に先の報告の状態で処理が停止していることがあります。

確かに本来は別の物を使うべきなのでしょうがGrep元が複数文字コード混在やGrep後にマクロで編集もしていたり宗教的な理由()で新規ソフトの導入が難しい等の事情もあって現時点ではサクラでバッチ処理しています。


[8036] Re10:コマンドラインからgrep処理について返信 削除
2015/5/13 (水) 22:36:38 匿名
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0
sakuraが起動しっぱなしになるのが「必ず」ではなく「まれ」なのであれば、
http://sakura.qp.land.to/?BugReport%2F107
ハズレかもしれないけれど、これの可能性はないでしょうか?
batからGrepの実行を連続で行っていて
スタートアップを常駐しないにすると問題が発生すると思います。
実際batで、Grep標準出力モードを連続して実行すると、
「エディタ間の対話に失敗しました」のエラーがたまにでます。
対策は、Grepの連続実行の間に数秒程度待つようにすればいいと思います。
待つのはbatからcscript sleep.js
//sleep.js
WScript.Sleep(3000);


[8037] Re11:コマンドラインからgrep処理について返信 削除
2015/5/15 (金) 10:53:13 すなっくぱん
Opera/9.80 (Windows NT 6.1) Presto/2.12.388 Version/12.17
▼ 匿名さん
情報ありがとうございます。
[8027]以前は常駐していて停止頻度が高かったので別原因だったとも思いますが
現在は常駐をやめているため、停止頻度は下がっていますが、そちらの報告が原因になっている可能性はありますね。
一応Grep後にfile open errorのチェック等もしていて、そこまで高速で連続という事はないですが念のためGrep実行前に数秒待たせてみようと思います。
ちなみにVista以降ならtimeout(.exe)というものが標準であります。

[▼次のスレッド]
INCM/CMT
Cyclamen v3.81