こんなんでいいんだろうか。未分類noWeb開発PHPGoogleCloudPlatformうまくカテゴれてないメニューはそのうちなんとか......。プログラミング::HSP3つーさ何で今更こんなモノ、とか思わないでもない。いうか、誰か似たようなモノ作ってるんじゃないのかなぁ、という感は否めないんだけど(笑しかも、何に使うんだコレ(笑x2今回は思ってたより時間かかってしまったなぁ。コード量も+100行くらい。なんで、pipe2なのかといえば、hspextのpipeの代替だから。pipeputは呼び出しただけでシステムエラーに^^;このモジュールはスクリプトに組み込んで自由に使用できます。操作できるモジュール。以下の命令を定義してます。子プロセスをパイプ付き実行。実行するコマンドライン。標準出力/標準エラー出力の(文字列/バイナリ)取得。以降を省略した場合、必要なサイズを勝手にbufに確保する(内容はクリアされる)。取得内容が文字列とわかっている場合は便利。offsetの指定は無効。標準入力へバイナリ書き込み。標準入力へ文字列書き込み。パイプの状況をチェック。以下のビットの組み合わせ。子が終了後でも受け取るモノは受け取れます。PM8時49分お返事ありがとうございます。>~ばっちり大丈夫でしょうか?全然ばっちりじゃないのです;あらためて確認してみると、取得できていない物がありました。むー・・・」ってな所です。エラー出力」や今回やっと重い腰を起こした事もあり、しっかりと学びたいと思います。~しにベーシックを触った程度だったので、なかなか頭に入らないんですけどね;理解しやすいお返事に本当に感謝しております、ありがとうございます。PM9時58分しっかり確認もせずにカキコしてしまいました、本当に申し訳ありません。取得したい部分は全て取得出来ていました、全てが一行ずつ取得できるものと思い込んでいて「長~く連なっていて気づかなかった」だけでした;どのような出力になっているのか、先に教えていただいた部分を学びながら修正していきたいと思います。勝手な書き込み、本当に失礼いたしました。無事にやりたいことが実現できましたようで何よりです。勝手な書き込みだなんてとんでもない。今後とも何かありましたが気軽にコメントいただければ幸いですー。AM10時01分その節は大変お世話になりました。理解が深まったかどうかは怪しいところですが、色々なものへ利用できて新たな発見ばかりで楽しんでいます。これまでの自分用ツールなんて全部作り直し(ほぼ要らないものですが)、何といっても今まで取得しにくかったエラーなども見えてしまうので大喜びです。(とんでもないミスを犯すこともまた楽しいです^^;)本当にありがとうございました、また何かあればよろしくお願いします。PM2時31分コメントありがとうございます。パイプが使えると、様々なコンソールアプリをプログラムから扱えるようになって便利ですよね。お役に立てればブログをやっていた甲斐があったというものです。有用な記事を書いていければと思いますので、こちらこそよろしくお願いします。PM11時09分また詰まってしまいました;元々GUIを持たないものに対して「GUI操作したい」と新たに進め始めたのですが操作に対して無反応。同じプログラムでGUIを持っているものに対しては問題なく動きます。そこで表示されないコマンドコンソールを表示して確認してみたいと思い、各命令を調べ始めたのですが頭に入りにくい年頃で;なかなか思うように進まず、また来てしまいました。どのようにしたらコマンドコンソールを表示させられるのでしょう。「調べてないだろ」程度なのであれば一番に関連している関数を教えていただくだけでも結構ですので、お力を貸していただけたら幸いです。AM1時50分コメントありがとうございます。パイプは直接関係がありません。「同じプログラムで」というのは、CUI版とGUI版があるものについて、その差異を指しているのでしょうか。GUIではなく、CUIを持っているものに対しては問題なく動く、のではないでしょうか?以下その前提で......。結論から言うと、できません。Windowsプログラムには標準入出力(≒コンソール≒CUI窓)を持つものと持たないものがあります。これはプログラム作成時に決めることであり、後から他のプログラムが変更することはできません。原則として、main()からプログラムが始まっているものはコンソールを持っていますがWinMain()で始まるものはコンソールを持たないようにコンパイル・リンクされます。mainで始めてもAPIを呼べばWin32のGUIウィンドウは作れますし、WinMainで始まってもAllocConsoleを呼べばコンソールを持てます(CUI窓が開きます)。操作対象としたいアプリがコンソールを持っていない場合は操作のしようがありません。何を入れても相手に受け取ってもらえない(プログラムがそういう作りになっていないため)のではないかと思います。コンソールを持たないGUIアプリケーションを操作したい場合は、標準入出力以外のプロセス間通信を行う必要があります。APIなどを利用し、操作対象のウィンドウを補足した上で、SendMessageやその他のUser32.dll内のAPIを用いて操作する、などの方法が一般的です。操作したい対象のウィンドウは、事前にSpy++を用いてウィンドウのタイトルやクラス名親子関係を調べておくと良いでしょう。何か根本的に外していましたら補足ください。AM10時03分ご返答ありがとうございます。はじめにお詫びいたします。自分自身が分かっているつもりでいい加減な言葉の使い方をしていたことに恥ずかしいです、申し訳ありません。かいつまんで調べて使っているレベルでは前に進めないということを痛感いたしました。コメントを見て気づきました、これまでのは対象がGUIを持っていると思っていたものが単に見た目が良くなったCUIでありました;>~標準入出力(≒コンソール≒CUI窓)~この辺りから勘違いがないように昼休みからでも調べなおします。ここからはしばらく投げておいてもらってかまいません^^;・Javaプログラムである・基本的にバッチファイルで起動する2つの対象があり、一つはオリジナルのウィンドウも使える(非表示時に「nogui」と記述することから色々と勘違い;オリジナルのウィンドウを持った物にないしては、つーささんのプログラムを利用することで自由に対話出来ていた。(そのつもり;)今回つまづいた対象がコマンドプロンプトで対話できている事から上記の様に簡単に対話できると思い、コマンド入力の簡略を目的としたプログラムを作りました。動かしてみたら対象が起動したが対話が出来ない。(Javaが起動し関連プログラムから正常に動いている事は確認済み)こんな状況であります。書いてしまい申し訳ありません、「CUIを持っているものに対して~」と合わせて調べていきたいと思います。何度も「見直し」にアクセスすると思いますが不審に思わないでくださいね^^;本当にありがとうございます。「単に見た目が良くなったCUI」という表現があるので、言葉の整理をさせてください。←たとえばこれが前者のCUI風オリジナルGUIです。←こっちがCUIです。このCUIには「Windows標準のコンソールに色を付けるなどして見やすくしたもの」も含まれます。←お目に掛かることは希ですが、こんなのもあります。気にしなくてはいけないのは、Windows標準のコンソールウィンドウ(私が言うCUI)の存在です。対象のアプリケーションが標準入出力を扱っている場合のみ、プロセス間通信が成立します。Windowsはコンソールアプリを単にダブルクリックして起動すると、標準入出力用にコンソールを開いてくれます。(コマンドプロンプトから起動した場合はすでにコンソールがあるので、その窓がそのまま使われます。)一般に標準入出力を扱いたいアプリケーションはコンソールアプリとして作られているはずなので、この窓が画面に出るかどうかは、そのアプリがコンソールアプリであるか、ひいては標準入出力を扱うことを期待しているかについての判断材料にすることができます。私がCUIが~と気にしたのにはそういうわけです。「<」リダイレクトを使ってキーボードで入力するはずのものを流し込めるか試してみてください。input.txt」とやれば、サーバが起動して終了するはずです。操作元プログラムの側で足下ミスを見落としている可能性を疑います。バッチファイル内でstartコマンドなどが使われると、コンソールが分かれてしまいますので意味がないので、バッチファイルは使わないようにしてください。逆にこれができなかった場合は、アプリの細かい設計がどうなっているか(ちょっと普通じゃないことをやっている)で......。想像を巡らせるしかないので、ここから先はアプリごとの個別対応になってくると思います。「nogui」という響きからすると、独自ウィンドウを開かず、コンソールだけで動作するものというイメージが沸きます。上記方法を使えば、画面に何も出さずにバックグラウンドでサーバを動かせるよ!という用途を期待したオプションでないかと推測です。私も知識浅く前のコメントでは勘違いしていたのですが、コンソールアプリケーションでなくとも、外から標準入出力用のハンドルを与えてやれば標準入出力を扱うことができるようです。(対象のアプリケーションがそういう風に作られていることが前提です)javaはコンソールアプリケーションで、javawはコンソールアプリケーションではないのですが、javawを使った場合でも、本モジュールでminecraftのサーバアプリとやりとりができていたので。何度も何度も本当にありがとうございます。Minecraftまで引っ張ってきてもらって分かりやすく、重ね重ねありがとうございます。標準入力かどうかについてグーグル先生とにらめっこしておりました;教えていただいた方法でMinecraftサーバで動作確認後に対象に対しても実行してみたところ、「stop」は受け取ってもらえませんでした。一気に力が抜けてしまいました^^;が、新しく覚えていきたい部分が明確な形で出てきました。経験と惰性でこなす機械の修理・改造などとは違いまるで生き物を触っているようです。コメントを読むたびに頭にあるイメージがずれていることを感じました。重ねてありがとうございます。新しい対象アプリにはそのアプリで有効な命令を書いてくださいね。大丈夫だと思いますが一応付け加えておきます。今回みたいなことをやるときは裏側もある程度知っていないと難しかったですね。私もリダイレクトができるかどうかを試せば良いことをとっとと思いついていれば......^^;私にとって、コンソールアプリケーションがどうとか標準入出力がどうとかというのは、C言語でWindowsアプリケーションを作ったことがあっての知識です。言葉をお借りすれば、それこそ経験と惰性だと思います。どのパーツがどんな仕事をしているかを知ってからでないと弄れないのは、ハードウェアでもソフトウェアでも似たようなものではないかなぁと思います。機械と比べて違うところは、それが想像の世界で完結している部分ですが......。人が作ったものであり、人類が作ってきたものですので。思想を一つ覚えれば、同じ思想に基づいた言語はみな方言・親戚のようなものだと思います。今回の、標準入出力という概念はUnixが元祖で、WindowsもLinuxもそれを真似た実装をしています。プログラミング言語も同じで、HSPはBasicを参考に作られていますし、CとC++とJavaとC#も似ています(もちろん違うところもいっぱいあります)。グループの中のどれか一つを覚えれば、他の言語のコードを読むことぐらいはできるようになったりします。自分の使える言語に翻訳さえすればできることが増えて楽しいです。(その点、HSPはマイナーな部類です)新しい分野に挑むときは、月並みですが、その世界に飛び込むつもりで希望をもって楽しくやることが大事だと思います。それそのものを触っていること自体が自分にとって楽しいとか、それを触って習得したその先に何かやりたいことがあるとか。仕事をするとき、せっかくオフィスの中にいるのに、わざわざジャングルに出る必要はない。オフィスの中ではどうしてもできないけど、ジャングルの向こうにやりたいことがある、そのとき初めてオフィスの外に出ればいいのではないでしょうか。私は、これがちょうどHSPとC言語の関係だと思っています。興味のある部分を皮切りに裾野を広げていけばいいのではないかと思います。楽しめそうにないことは縁がなかったということで、それでもやりたければやるまでで(笑もし他の言語に手を出すのでしたら、個人的にはC#を推しておきます。数ある言語の中では比較的ハードルが低く、プログラミングの学習とソフトウェア作りが両立できると思います。APIをばりばり使いこなしているぜと感じているとしたらC言語の方が近道だと思います)最近トレンドな言語はオブジェクト指向ベースのものが多い(C++とかJavaとかObjective-CとかC#とか)ので、オブジェクト指向についてもぼんやりと抑えておくと、その手の言語を勉強をするときに役に立つかと思います。HSPでも「モジュール変数」というのがあって、不完全ながらオブジェクト指向っぽいことができたりします。なんかちょっと上からものを言われているように感じられたら申し訳ありませんが、ご参考まで。PM2時16分ありがとうございます、長いなど全然そんなことはありませんよ。10ページ程度なら全て読んじゃうほどの内容でした。Frameworkの無い環境の場合には使えない・インストールが必要というところで手をつけませんでした^^;もう20年以上も前にBasicを少し触り、オンラインゲームが広がり始めた10年ほど前にHTMLに少し触れてホームページを公開していた時期もありました。HSPに出会いBasicに似ている事やエディタへの馴染みやすさから現在に至っています。その少し前にVBを触ったのですが、HSPでウィンドウを表示した瞬間にVBのことなど忘れてしまいました。時間がかかっていました。今ではWeb上にサンプルが転がっているので、動作確認までの時間がかかりませんしエディタのおかげで何の準備も無く実行ファイル化。必要なところだけ欲しい自分にとってはとても有意義なことなのですが、「覚えていたほうがいい」という優先順位の低い部分を記憶できない欠陥のある頭なのでいいことばかりではありません(--人の名前すら記憶できない酷いときにはそこそこ関係のあった人自身を覚えていないほど、プログラミングに向いていないのかもしれませんね^^;Win32APIもMicrosoftのページを見て理解できることはまれで、たくさんあるサンプルを手当たり次第に動かして初めて一つの関数の動きが「見える」程度です。HSPの「モジュール」もなんとなく動作は知っていますが、公開されているものは内容が複雑で結果を得るための工程はほとんど理解できません。見やすく分けていてもスクリプトが長くなると面倒すぎます。あとはメモリ使用量が気になってます、環境毎に違うようですが理由などは調べてもいません^^;タスクトレイ常駐型のものを作っていたりもするので出来るだけ使用量は抑えたいところです、自分用では適当なところでリスタートさせて誤魔化してたり・・・。確保したバッファのクリアは調べたのですが、再確保時に以前の量を超えると問題になる様な動きをするとか?この辺も調べていきたいところです。とりとめも無く書いてしまいましたが(日曜のせい?)とても参考になる内容で、これを書いている時にも何度も読み直しています。本当にありがとうございますm(__)m最後に、趣味は「車」です。AM1時07分とりとめもなく。2.0が出て、以降だんだんC#ばかり使うようになってきて、今は大概のことはC#でやっているという感じに。Studioというツールの使い方さえわかるとHSPより遙かに楽にプログラムが書けるので......。今はOSにフツーにくっついてくるのでいい時代になったなぁと思います。2.0が出たころは流行らない技術だと思っていましたが、全然そんなことはなかった(笑サンプルを見ないとAPIの使い方がわからないのは私も同じですが、ただ動いた、というところまでではなくて、その先、どのコードが何をしてるのかをきちんと読み解くことが大事かと思います。ここで得た細かい情報は覚える必要はなくて、どこにどんな情報が眠っていたかというのを'経験'として持つと次に、ググりやすかったり、サンプルを探しやすかったり、といった'勘'が働くようになると思います。私は、実際にコードを動かしてみることもありますが、どちらかというと全体を眺めて、たぶんこんな風に動くんだろうなと頭の中で想像して終わることが多いです。そんな私は人の名前を覚えるのがすこぶる苦手です。こんなんではいかんと思いつつ、どうしても(汗プログラミングに関しては、フィーリングで何とかやってます。HSPのモジュールは便利な機能ですね。使えるようになったらいいと思います!モジュールとして名前空間を分けて新しい命令を作った方が、サブルーチンを使うよりも気にすることが減るので、精神衛生上良いですし。綺麗なモジュールを作ろうとすると、機能をうまく部品に分ける力がつきますし。最初はmamoさんのスクリプトの中でサブルーチンになっている部分の機能をモジュールに分離することから始めるのがいいのではないかと思います。#ちなみにHSPではモジュールにしなくてもスクリプトファイルを分割できます(?メモリの使用量に関しては。何を以てメモリの使用量というかにもよりますが、HSPを使っている以上は、その辺は自動的によしなにやろうとしてくれるので、アバウトに捉えておいた方がいいのではないかなぁとは思います。1GBのメモリを確保しなければ1GBのメモリが確保されることはありませんし。私自身は、使うマシンが贅沢になってしまって、メモリもGB単位まで行かない限りはほとんど気にしなくなってしまいました。どこでも動くプログラムを作るにはあんまり良くないのですけど。使える資源を使わないようにケチってしまったがために、できることが制限されたり窮屈な思いをしたりするのは本末転倒だとも思います。一部の環境でしか動かないけれど、最新技術をふんだんに取り入れたすごいソフトウェア。それはそれでいいよなぁと思います。スペース化は、まずは素直に作ってみた後、それで間に合わないときに考える!(笑HSPのメモリ管理について細かく学んでいくと、HSPはどういうときにどうやってメモリを確保するのかに行き着くのかと思います。使う側として調べるよりは、内部仕様に踏み込んで、HSPがどんな風にメモリ上にデータを配置しているのかを調べると、なぜ再確保したときに問題があるのか、勘みたいなものが得られる、かもしれません。得られないかもしれません。再確保時の問題とは、メモリのコピーが起こることを指しているのかなと思いますが、問題というほどのものでもないような、あるいは私が知らないHSPのバグがあるのかもしれません。納得のいく答えを探してみてください。PM10時49分しばらく時間を置かせていただき、読み返えさせていただきました。これがなかなか・・・その後に少し試していて「リダイレクト」のくだりを思い出し、目的のプログラムをコマンドプロンプトで標準エラー出力?にてファイルへの出力の出来ることが分かりました。)コマンドプロンプトに入力したものもファイルへ出力されているので、ログはそちらを読み込む形にしてコマンド入力はクリップボード経由で入力する事でごまかしてみました(自分用って事で・・・。ここにあるスクリプトを舐めまくっていますが少しも進むことが出来ていませんが、どこで何を行っているのかはぼんやりと掴めてきたかなと感じてがんばっています。進む気でいますので、何かあったときにはお力をお借りできれば幸いです。PM11時34分コメントありがとうございます。リダイレクトでファイル出力できるということは、このモジュールで(入力はできないけど)出力を読み取ることはできるかと思います。ファイルを経由しなくてもよいかもしれません。AM5時22分こんにちは。返事が遅くなってごめんなさい。いう動作をするソフトか把握していないので以下推測です。(ffmpegのそれかなと思うけど、ちょっと試している時間がない......。標準エラー出力には何かしらはき出されていて、取得できる状態になっているものと思います。ところに対象のコマンドラインを記載して何か出るか試してみてください。はき出して、カーソルをその行の頭に戻し、数字だけ変えて文字を上書き出力しているものと思います。これはコンソールアプリを書くときのテクニックです。そのまま文字を出力することで上書きできるため、進捗表示などでよく使われます。なるか試してみてください。命令は改行や復帰などは扱わず、そのまま溜め込むため、pipe2xxxを呼び出した時点で過去にパイプにはき出されたものがすべて取得できると思います。いう文字列が得られるはずです。区切り文字として$0Dを渡すと、たぶん期待する処理が実現できます。プログラムが標準エラー出力をいつまでも読み出さないと、詰まったパイプがタイムアウトで壊れてコンソールに流れ出てしまっている、のかな?(恐らく)上記試してみて解決しないようであればまたコメントください。HSPの"\n"はC言語でいう"\n"($0A)ではなく"\r\n"($0D$0A)を意味するため、混同しないようにしてください。パイプに入力したりするときに注意が必要な場合もあります。うまく入力が効かないという場合はその辺も考慮してみてください。PM6時38分こんにちは。現象を認識したので、いろいろ調べてみました。いう結論......。サンプル2をいじってると、どうも4096バイトごとに固まって流れてくるっぽい。試してみたが効果なし。CygwinのTerminal上で単にプログラムを実行した場合でもバッファされて出てくる。ffmpegのソースを参照したところ、ffplayはログの出力時にfflushを呼んでなさそう。正攻法は「ffplay側のソースをfflushを呼び出すように改造してビルドしなおす」ということになります。ログ出力時にfflush呼んでほしいですとFFmpegの中の人に言う。別の解決方法として、「非表示のコンソールウィンドウを作って、そこに吐き出されたものを頑張って読み取る」という方法をとってる人がいました。http://www.codeproject.com/Articles/16163/Real-Time-Console-Output-Redirection作者曰く「プロセス間で同期できないので、スクロールしたり画面クリアしたりのタイミングで取りこぼすかも」とのこと。そもそも復帰文字を出力してくるようなプログラム(ffplayとか)は、実質コンソールウィンドウの内容を自分で消しちゃうので、監視の頻度やらたまたま同じ文字が2回出力された場合に別の出力として認識できるようにするにはとか、色々創意工夫は要するかも。返せばいいよって書いてる人もいるhttp://www.codeproject.com/Messages/4543829/Pipe-pseudo-driver.aspxUserModeドライバだけで実現できるのかどうかよくわからない。KernelModeが必要になっちゃうと、Windows自体をテストモードで起動しないと動かない。_isattyの呼び出しが真を返せばよい)ような気もするので、APIフックとかDLLインジェクションとかの手法を使って、APIの返答を書き換える手があるかもしれない。これはこれで、CPUのDEPに引っかかったり、セキュリティソフトに阻まれたりしそう。ああ、さくっと使えるFILE_TYPE_CHARな仮想デバイスはないのかしら......。いうのが今のところです。これが標準エラー出力のバッファを読み出さないことによるエラーの発生だと思いCランタイム内の出力バッファに溜まるのは仕様で、そのバッファが溜まりきって実際にパイプに書き出そうとした時に、パイプ側のバッファがいっぱいになっていてブロッキングしているのだと思います。これは、上のCランタイムのバッファの仕様とは直接関係はないです。