doyle
New Member
Posts: 44
|
Post by doyle on Apr 29, 2010 23:58:48 GMT 1
Hi, seems pretty dead on the new forum. Has anyone got an example of how to pipe stdout, stderr to a gtk textview? Thanks for any pointer. A C example will do but BaCON code would be even better! ;D Thanks, Doyle
|
|
|
Post by Pjot on Apr 30, 2010 7:36:56 GMT 1
Hi Doyle,
I am not sure what you want to achieve, but maybe EXEC$ can help you:
txt$ = EXEC$("myprogram 2>&1") gtk_text_buffer_set_text(TxtBuffer, txt$, -1) [...]
The '2>&1' construct in the EXEC$ will redirect stderror to stdout.
Peter
|
|
doyle
New Member
Posts: 44
|
Post by doyle on May 9, 2010 18:46:31 GMT 1
Hi Doyle, I am not sure what you want to achieve, but maybe EXEC$ can help you: txt$ = EXEC$("myprogram 2>&1") gtk_text_buffer_set_text(TxtBuffer, txt$, -1) [...]
The '2>&1' construct in the EXEC$ will redirect stderror to stdout. Peter Thanks Peter, this seems to work up to a point. I am redirecting stdout and stderr to a textview in my program, specifically i'm catching the output from the bacon translate/compile process. But using the code you gave seems to not get all of the text from the console. For example I have a file with 56 lines of code and I get the following text output to my textview: ... ... Starting conversion... 47 Starting conversion... 48 Starting conversion... 49 That's all of the output I get. Why doesn't it grab the rest of the lines? Some buffer to small somewhere? I've tried to find some c code to do this but can't seem to find a good c example or I'm to dense. ;-) In Windows, I would use CreateProcess and grab the console output but on linux I'm lost. Thanks, Doyle
|
|
airr
New Member
Posts: 47
|
Post by airr on May 10, 2010 3:18:11 GMT 1
popen is the simplist way. This is BCX syntax, but I think you'll get the idea: dim fpipe as FILE dim cmdarg$,buf as string * 256 cmdarg$="ls -l" fpipe = popen(cmdarg$,"r") if not fpipe then perror("Problems with pipe") end = 1 end if while not eof(fpipe) line input fpipe,buf print buf wend pclose(fpipe) GLib will allow you to set a "monitor" via callbacks that will do what you need, but it's more involved: scentric.net/tmp/spawn-async-with-pipes-gtk.cA.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on May 10, 2010 10:45:55 GMT 1
Welcome back to the Basic world. We missed you. There is still a plate for you at the BCX table if you get the munchies.
|
|
|
Post by Pjot on May 10, 2010 18:16:38 GMT 1
Hi Doyle, Sorry it took some time (was away for my job) but in the meantime I have found the reason. The EXEC$ statement in fact forks a subshell where the command is executed, but the parent reads 'to fast' from the pipe towards the subshell. After one read, the parent process has digested the output from the subshell and reads again from the pipe, which in fact is not filled up to the full buffer size. BaCon however thinks if the pipe is not full completely, the subshell is ready and it quits the connection. Therefore we receive partial results. So this is a bug, only occuring in a situation where a command produces large output printed slowly. It is fixed in build 13 which you can obtain from the BETA directory. Please let me know if the fix works for you. Regards Peter
|
|
doyle
New Member
Posts: 44
|
Post by doyle on May 11, 2010 0:42:50 GMT 1
Hi Doyle, Sorry it took some time (was away for my job) but in the meantime I have found the reason. The EXEC$ statement in fact forks a subshell where the command is executed, but the parent reads 'to fast' from the pipe towards the subshell. After one read, the parent process has digested the output from the subshell and reads again from the pipe, which in fact is not filled up to the full buffer size. BaCon however thinks if the pipe is not full completely, the subshell is ready and it quits the connection. Therefore we receive partial results. So this is a bug, only occuring in a situation where a command produces large output printed slowly. It is fixed in build 13 which you can obtain from the BETA directory. Please let me know if the fix works for you. Regards Peter Thanks Peter, it works great in build 13. I appreciate it. Doyle
|
|
doyle
New Member
Posts: 44
|
Post by doyle on May 11, 2010 0:46:18 GMT 1
Welcome back to the Basic world. We missed you. There is still a plate for you at the BCX table if you get the munchies. I do get the munchies from time to time. My work is going strong in the busy season and I don't have much time for BCX or BaCON. Doyle
|
|
doyle
New Member
Posts: 44
|
Post by doyle on May 11, 2010 0:50:52 GMT 1
popen is the simplist way. This is BCX syntax, but I think you'll get the idea: dim fpipe as FILE dim cmdarg$,buf as string * 256 cmdarg$="ls -l" fpipe = popen(cmdarg$,"r") if not fpipe then perror("Problems with pipe") end = 1 end if while not eof(fpipe) line input fpipe,buf print buf wend pclose(fpipe) Thanks, I actually ran across almost the same code but it looked to "simple" to work. Of course, I'm thinking of CreateProcess in Windows too. I guess I've got a lot to learn using linux. ;D Ouch, that's beginning to look like Windows code... Thanks! Doyle
|
|