Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
|
|
|
22 crawler(s) on-line.
95 guest(s) on-line.
0 member(s) on-line.
You are an anonymous user. Register Now! |
|
|
|
| Poster | Thread | Wanderer
|  |
Reading STDOUT from another Tool Posted on 17-Mar-2013 22:48:16
| | [ #1 ] |
| |
 |
Cult Member  |
Joined: 16-Aug-2008 Posts: 654
From: Germany | | |
|
| Hello!
I want to run (asynchroneously) an external program from my own program. I use SystemTagList() for that, nothing wrong so far I guess.
Everything works fine.
Now, I want to get the text that the external program writes to STDOUT. Letting it pop up by redirecting to CON: or somthing wont help, I want to get my hands dirty on the output text for further processing.
My current, but not satisfying solution, looks like this:
I launch a new process that listens to "PIPE:mysecret", via Open(), and hangs in a Read(fh,buffer,1). Then I launch my external tool "MyTool >PIPE:mysecret". Once "MyTool" is done, it closes the pipe and Read() returns with 0 instead of the 1 when reading, and we are done.
What I dont like about his:
1. Reading one byte at a time is inefficient. I read only one byte because I want to output the text in realtime, not after the tool is done. Think of LAME's progress output or a compiler output. But if I read, say 32 bytes at one call, some text might come out delayed.
2. The user needs to have PIPE: mounted, otherwise my program causes "Insert PIPE: in any device", which may cause my program to not function properly if the user refuses to mount PIPE:
3. The seperate process is not so easy to handle for me. It must share some memory with the main process to pass information along, which makes the whole thing not proper functioning if the code is a library. Also, since the text doesnt flow into the main process, I have to send it via messages to the main process which introduces even more overhead.
Via SystemTagList(), I have control over Input() and Outout() file handles, but I dont get a clever idea how to make use of it.
A way to find out how much data I can read from the PIPE: without getting blocked would already help a bit, then I could read all available data in one call, and then "wait" via Read(fx,buff,1) until more data arrives.
Thanks for any hints!
Last edited by Wanderer on 17-Mar-2013 at 11:00 PM. Last edited by Wanderer on 17-Mar-2013 at 10:53 PM. Last edited by Wanderer on 17-Mar-2013 at 10:53 PM. Last edited by Wanderer on 17-Mar-2013 at 10:52 PM. Last edited by Wanderer on 17-Mar-2013 at 10:48 PM.
_________________ -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more... Homepage: http://www.hd-rec.de |
| | Status: Offline |
| | arsipaani
|  |
Re: Reading STDOUT from another Tool Posted on 18-Mar-2013 3:56:00
| | [ #2 ] |
| |
 |
Regular Member  |
Joined: 29-Mar-2008 Posts: 120
From: Unknown | | |
|
| @Wanderer
Not coded in amiga for long time but....
Is there popen() implementation ?
SystemTagList has NP_Output ... open your own "file", and read outputfrom there ? |
| | Status: Offline |
| | broadblues
 |  |
Re: Reading STDOUT from another Tool Posted on 18-Mar-2013 8:01:41
| | [ #3 ] |
| |
 |
Amiga Developer Team  |
Joined: 20-Jul-2004 Posts: 4456
From: Portsmouth England | | |
|
| @Wanderer
Quote:
I launch a new process that listens to "PIPE:mysecret", via Open(), and hangs in a Read(fh,buffer,1). Then I launch my external tool "MyTool >PIPE:mysecret". Once "MyTool" is done, it closes the pipe and Read() returns with 0 instead of the 1 when reading, and we are done.
|
Seem reasonable.
Quote:
1. Reading one byte at a time is inefficient. I read only one byte because I want to output the text in realtime, not after the tool is done. Think of LAME's progress output or a compiler output. But if I read, say 32 bytes at one call, some text might come out delayed.
|
Use buffered io and IDOS->FReadLine() for AmigaOS4 or clibrary buffered io and readln() for older versions. You ofcourse need to open the end of the pipe passed to the subtask with IDOS->Open() whichever way you go.
Quote:
2. The user needs to have PIPE: mounted, otherwise my program causes "Insert PIPE: in any device", which may cause my program to not function properly if the user refuses to mount PIPE:
|
PIPE: is pretty standard, users who fail to install standard libs and devices, get what they deserve, and should not be catered for.
Quote:
3. The seperate process is not so easy to handle for me. It must share some memory with the main process to pass information along, which makes the whole thing not proper functioning if the code is a library. Also, since the text doesnt flow into the main process, I have to send it via messages to the main process which introduces even more overhead.
|
Reading that I realise I slightly misunderstood your first setup decsription,
you do it like so.
(pseudo code)
MAINTASK:
BPTR WriteFH = Open("PIPE:someunique name/buffersize/0",MODE_NEWFILE); BPTR ReadFH = Open(""PIPE:someunique name/buffersize/0",MODE_OLDFILE);
CreateNewProcessTags( NP_Entry, mynewtask, NP_Input,Input(), NP_CloseInput,FALSE, NP_OutPut,WriteFH, NP_CloseOuput,TRUE, NP_Arguments,"C:somecommand arg1 arg2 arg3", a range of other tags depending on OS version TAG_DONE);
while(condition) Read(ReadFH) Do stuff ) Close(ReadFH)
Wait(signalfromchild)
REST OF PROGRAM:
----
mynewtask(STRPTR args, int32 length , (execbase if PPC OS4)) { System(args); // synchronous!!!!
Signal(parenttask,signalfromchild); }
That is really really rough, I know, there is a complete version in the abc-shell source or the perl source (perl developed from abc-shell) I don;t have the code immediatly to hand and perl and abc-shell have the additional complication of interacting with the parents Clibrary filehandles....)
Last edited by broadblues on 18-Mar-2013 at 08:03 AM.
_________________ BroadBlues On Blues BroadBlues On Amiga Walker Broad |
| | Status: Offline |
| | broadblues
 |  |
Re: Reading STDOUT from another Tool Posted on 18-Mar-2013 8:13:48
| | [ #4 ] |
| |
 |
Amiga Developer Team  |
Joined: 20-Jul-2004 Posts: 4456
From: Portsmouth England | | |
|
| @broadblues
Okay here's the abc-shell code. AS you can see it does a lot more than you need. Hopefully you can pick out the parts you need.
int execve(const char *filename, char *const argv[], char *const envp[]) { FILE *fh; char buffer[1000]; size_t size = 0; char **cur; char *interpreter = 0; char * interpreter_args = 0; char *full = 0; char *filename_conv = 0; char *interpreter_conv = 0; char *fname; struct Task *thisTask = FindTask(0);
FUNC;
/* Calculate the size of filename and all args, including spaces and quotes */ size = 0; for (cur = (char **)argv+1; *cur; cur++) { size += strlen(*cur) + 1 + (contains_whitespace(*cur)?(2 + no_of_escapes(*cur)):0); }
/* Check if it's a script file */ fh = fopen(filename, "r"); if (fh) { if (fgetc(fh) == '#' && fgetc(fh) == '!') { char *p; char *q; fgets(buffer, sizeof(buffer)-1, fh); p = buffer; while (*p == ' ' || *p == '\t') p++;
int buffer_len = strlen(buffer); if ( buffer_len > 0 ) { if(buffer[buffer_len-1] == '\n') { buffer[buffer_len-1] = '\0'; } }
if ((q = strchr(p,' '))) { *q++ = '\0'; if(*q != '\0') { interpreter_args = strdup(q); } } else interpreter_args = strdup("");
interpreter = strdup(p); size += strlen(interpreter) + 1; size += strlen(interpreter_args) +1; }
fclose(fh); } else { /* We couldn't open this why not? */ if(errno == ENOENT) { /* file didn't exist! */ return -1; } }
/* Allocate the command line */ if (filename) filename_conv = convert_path_u2a(filename);
if(filename_conv) size += strlen(filename_conv);
size += 1 + 10; /* +10 for safety */ full = malloc(size); if (full) { if (interpreter) { interpreter_conv = convert_path_u2a(interpreter); #if !defined(__USE_RUNCOMMAND__) sprintf(full, "%s %s %s ", interpreter_conv, interpreter_args,filename_conv); #else sprintf(full, "%s %s ",interpreter_args, filename_conv); #endif free(interpreter); interpreter = NULL; free(interpreter_args); interpreter_args = NULL;
if(filename_conv) { free(filename_conv); filename_conv = NULL; }
fname = strdup(interpreter_conv);
if(interpreter_conv) { free(interpreter_conv); interpreter_conv = NULL; } } else { #ifndef __USE_RUNCOMMAND__ snprintf(full, size, "%s ", filename_conv); #else snprintf(full, size, "%.*s", 0, ""); #endif fname = strdup(filename_conv); if(filename_conv) { free(filename_conv); filename_conv = NULL; } }
for (cur = (char**)argv+1; *cur != 0; cur++) { if(contains_whitespace(*cur)) { int esc = no_of_escapes(*cur); if(esc > 0) { char *buff=malloc(strlen(*cur) + 4 + esc); char *p = *cur; char *q = buff;
*q++ = '"'; while(*p != '\0') { if(*p == '\n'){ *q++ = '*'; *q++ = 'N';p++;continue;} else if(*p == '"'){ *q++ = '*'; *q++ = '"';p++;continue;} else if(*p == '*' ){ *q++ = '*';} *q++ = *p++; } *q++ = '"'; *q++ = ' '; *q='\0'; strncat(full, buff, size); free(buff); buff = NULL; } else { strncat(full, "\"", size); strncat(full, *cur, size); strncat(full, "\" ", size); } } else { strncat(full, *cur, size); strncat(full, " ", size); }
} strncat(full, "\n", size);
if (envp) createvars(envp);
#ifndef __USE_RUNCOMMAND__ lastresult = SystemTags(full, SYS_UserShell,true, NP_StackSize, ((struct Process *)thisTask)->pr_StackSize, SYS_Input,((struct Process *)thisTask)->pr_CIS, SYS_Output,((struct Process *)thisTask)->pr_COS, SYS_Error,((struct Process *)thisTask)->pr_CES, TAG_DONE); #else if (fname){
BPTR seglist = LoadSeg(fname); if(seglist) { /* check if we have an executable */ struct PseudoSegList *ps = NULL; if(!GetSegListInfoTags( seglist, GSLI_Native, &ps, TAG_DONE)) { if(!GetSegListInfoTags( seglist, GSLI_68KPS, &ps, TAG_DONE)) { GetSegListInfoTags( seglist, GSLI_68KHUNK, &ps, TAG_DONE); } }
if( ps != NULL ) { SetProgramName(fname); lastresult=RunCommand(seglist,((struct Process*)thisTask)->pr_StackSize, full,strlen(full)); errno=0; } else { errno=ENOEXEC; } UnLoadSeg(seglist); seglist = 0; } else { errno=ENOEXEC; } free(fname); fname = NULL; }
#endif /* USE_RUNCOMMAND */
free(full); full = NULL; FUNCX; if(errno == ENOEXEC) { return -1; } else { return lastresult; } }
if(interpreter) { free(interpreter); interpreter = NULL; }
if(filename_conv) { free(filename_conv); filename_conv = NULL; }
errno = ENOMEM;
FUNCX; return -1; } #endif /* newlib */
int pause(void) { fprintf(stderr,"Pause not implemented\n");
errno = EINTR; return -1; }
struct userdata { struct op *t; int flags; struct Task *parent; };
LONG execute_child(STRPTR args, int len) { struct op *t; int flags; struct Task *parent; struct Task *this; struct globals globenv;
this = FindTask(0); t = ((struct userdata *)this->tc_UserData)->t; flags = ((struct userdata*)this->tc_UserData)->flags; parent = ((struct userdata*)this->tc_UserData)->parent;
copyenv(&globenv); e->type=E_SUBSHELL; if(!(ksh_sigsetjmp(e->jbuf,0))) { execute(t, flags & (XEXEC | XERROK)); } else { lastresult = exstat; } restoreenv(&globenv); #if !defined(__amigaos4__) Forbid(); Signal(parent, SIGBREAKF_CTRL_F); #endif
return 0; }
int exchild(struct op *t, int flags, int close_fd) /* used if XPCLOSE or XCCLOSE */ { /*current input output*/ int i; /*close conditions*/ long amigafd[3]; int amigafd_close[3] = {0, 0, 0}; struct Process *proc = NULL; struct Task *thisTask = FindTask(0); struct userdata taskdata;
char *name = NULL;
FUNC; if(flags & XEXEC) { execute(t,flags&(XEXEC | XERROK)); // this calls execve() eventualy }
taskdata.t = t; taskdata.flags = flags & (XEXEC | XERROK); taskdata.parent = thisTask; for(i = 0; i < 3; i++) { __get_default_file(i, &amigafd[i]); if(close_fd == i) amigafd_close[i] = true; }
if(t->str) { name = strdup(t->str); } else { name = strdup("new sh process"); }
proc = CreateNewProcTags( NP_Entry, execute_child, NP_Child, true, NP_StackSize, ((struct Process *)thisTask)->pr_StackSize, NP_Input, amigafd[0], NP_Output, amigafd[1], NP_CloseOutput, false, NP_CloseInput, false, NP_Error, amigafd[2], NP_CloseError, false, NP_Cli, true, NP_Name, name, NP_CommandName, name, #ifdef __amigaos4__ NP_UserData, (int)&taskdata, NP_NotifyOnDeathSigTask, thisTask, #endif TAG_DONE);
if ( proc != NULL ) { #ifndef __amigaos4__ #warning this code has been included! proc->pr_Task.tc_UserData = &taskdata; Wait(SIGBREAKF_CTRL_F); #else Wait(SIGF_CHILD); #endif }
free(name); name = NULL; // for(i=0; i < 3; i++) // if(amigafd_close[i] && (flags & (XPCLOSE))) // { if((i=close_fd) >=0 && (flags & XPCLOSE) ) { #ifdef USE_TEMPFILES BPTR f=0; UBYTE pname[256];
if(flags & XPIPEI) { __get_default_file(i,&f); NameFromFH(f,pname,sizeof(pname)-1); }
close(i); if(f) { DeleteFile(pname); } #else /* using true pipes */
if(flags & XPIPEI) {
char buffer[256]; int n,t; t = 0; while((n = read(i,buffer,sizeof(buffer)-1)) > 0) t +=n; }
close(i); #endif /* USE_TEMPFILES */
}
FUNCX; return lastresult; }
_________________ BroadBlues On Blues BroadBlues On Amiga Walker Broad |
| | Status: Offline |
| | Wanderer
|  |
Re: Reading STDOUT from another Tool Posted on 18-Mar-2013 13:26:45
| | [ #5 ] |
| |
 |
Cult Member  |
Joined: 16-Aug-2008 Posts: 654
From: Germany | | |
|
| @broadblues
Thanks for all the input. Will need some time to digest this. But I think you got my concept slightly wrong, or I did yours.
I will preare a better discription. But after all looks like the PIPE: is the way to go. I _________________ -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more... Homepage: http://www.hd-rec.de |
| | Status: Offline |
| | Wanderer
|  |
Re: Reading STDOUT from another Tool Posted on 18-Mar-2013 15:37:15
| | [ #6 ] |
| |
 |
Cult Member  |
Joined: 16-Aug-2008 Posts: 654
From: Germany | | |
|
| @Wanderer
It looks currently like this:
Main Program Pipe Listener MyTool . . . . . . . . . void RunMyToolAsync() { . . . CreateNewProc() -------> fh = Open("Pipe:unique",#MODE_OLDFILE) while (Read(fh,buffer,1)) { [send buffer to Event Loop] } Close(fh) . return . . SystemTagList("MyTool >Pipe:unique") --------> printf("Hello World!") return return } . . . [Event Loop]
_________________ -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more... Homepage: http://www.hd-rec.de |
| | Status: Offline |
| | Wanderer
|  |
Re: Reading STDOUT from another Tool Posted on 18-Mar-2013 15:42:42
| | [ #7 ] |
| |
 |
Cult Member  |
Joined: 16-Aug-2008 Posts: 654
From: Germany | | |
|
| @Wanderer
If the Pipe would Signal() my main program and tell me how much data I can read without blocking, the whole listener would not be needed.
If found "WaitForChar()", maybe I can use this? It looks like non-blocking and tells me that at leat one byte can be read from handle.
_________________ -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more... Homepage: http://www.hd-rec.de |
| | Status: Offline |
| | broadblues
 |  |
Re: Reading STDOUT from another Tool Posted on 18-Mar-2013 15:45:50
| | [ #8 ] |
| |
 |
Amiga Developer Team  |
Joined: 20-Jul-2004 Posts: 4456
From: Portsmouth England | | |
|
| @Wanderer
No, from reading you diagram I didn't get your concept wrong. You have three tasks ,the parent process ,the listener process and the command process.
Mine had own two as the parent and listener are one and the same.
Unless you have a specific reason for the listener to asynchronous from the parent, I would say mine is the easier to control. and is the way most scripting languages perl, ksh, python etc handle an external command.
_________________ BroadBlues On Blues BroadBlues On Amiga Walker Broad |
| | Status: Offline |
| | Wanderer
|  |
Re: Reading STDOUT from another Tool Posted on 18-Mar-2013 15:47:10
| | [ #9 ] |
| |
 |
Cult Member  |
Joined: 16-Aug-2008 Posts: 654
From: Germany | | |
|
| @broadblues
My main process is the GUI process and should not be blocked. This is the reason for the asynchroneous listener, but I would highly prefer to get rid of it since its not really comfortable for me for various reasons.
Last edited by Wanderer on 18-Mar-2013 at 03:48 PM.
_________________ -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more... Homepage: http://www.hd-rec.de |
| | Status: Offline |
| | broadblues
 |  |
Re: Reading STDOUT from another Tool Posted on 18-Mar-2013 16:01:11
| | [ #10 ] |
| |
 |
Amiga Developer Team  |
Joined: 20-Jul-2004 Posts: 4456
From: Portsmouth England | | |
|
| @Wanderer
Quote:
If the Pipe would Signal() my main program and tell me how much data I can read without blocking, the whole listener would not be needed.
|
Unfortunatly we don;t have SIGPIPE in amigaworld.
Quote:
If found "WaitForChar()", maybe I can use this? It looks like non-blocking and tells me that at leat one byte can be read from handle.
|
Might do. Although the autodocs say: Note that WaitForChar() is only valid if the I/O stream is connected to a virtual terminal device, you could try, it might depend on the pipe handler
AmigaOS4 has the more powerful WaitForData() which explicitly metion pipes in the docs, but ofcourse is only useful on OS4
_________________ BroadBlues On Blues BroadBlues On Amiga Walker Broad |
| | Status: Offline |
| | broadblues
 |  |
Re: Reading STDOUT from another Tool Posted on 18-Mar-2013 16:09:48
| | [ #11 ] |
| |
 |
Amiga Developer Team  |
Joined: 20-Jul-2004 Posts: 4456
From: Portsmouth England | | |
|
| @broadblues
OS4 Pipe has extra options too,
/BLOCK - If the pipe fills up, block further writes until data has been removed from the pipe by reading (V50). If there is no data to be read from a pipe just yet, wait for further data to arrive (V51).
/NOBLOCK - If the pipe fills up, refuse to store further data in it. Subsequent write requests will be rejected until some data has been read from the pipe (V50). If there is no data to be read from a pipe just yet, return an error rather than waiting for further data to arrive (V51).
maybe a third party pipe might do somthing similar on 3.x ?
_________________ BroadBlues On Blues BroadBlues On Amiga Walker Broad |
| | Status: Offline |
| | Wanderer
|  |
Re: Reading STDOUT from another Tool Posted on 18-Mar-2013 16:14:47
| | [ #12 ] |
| |
 |
Cult Member  |
Joined: 16-Aug-2008 Posts: 654
From: Germany | | |
|
| @broadblues
Hm, I need it to work under OS3.x, and I dont want to make my program depednent on 3rd party software, only the OS itself.
Under this circumstances you agree that the listener process is necessary (with all its overhead, since I am not allowed to modify the GUI elements directly from another thread than the GUI thread), or is there something else I could try?
(ok, WaitForChar could solve the blocking problem, but then my main program must poll from the pipe which is not nice either.)
Last edited by Wanderer on 18-Mar-2013 at 04:15 PM.
_________________ -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more... Homepage: http://www.hd-rec.de |
| | Status: Offline |
| | broadblues
 |  |
Re: Reading STDOUT from another Tool Posted on 18-Mar-2013 16:46:58
| | [ #13 ] |
| |
 |
Amiga Developer Team  |
Joined: 20-Jul-2004 Posts: 4456
From: Portsmouth England | | |
|
| @Wanderer
Quote:
Hm, I need it to work under OS3.x, and I dont want to make my program depednent on 3rd party software, only the OS itself.
|
Quite undertsandable. I think the 3.x pipe was less broken than the 2.x one, but still has limitations. I think that's why ixemul introduced it's own.
Quote:
Under this circumstances you agree that the listener process is necessary (with all its overhead, since I am not allowed to modify the GUI elements directly from another thread than the GUI thread), or is there something else I could try?
|
Well the only thing that springs to mind as an alternative, might be to write your own handler, but that's non trivial to say the least! Quote:
(ok, WaitForChar could solve the blocking problem, but then my main program must poll from the pipe which is not nice either.)
|
Yes*if* WaitForChar() worked with pipes, it would still be a busy wait solution, so might need a timer to poll more nicely.
This just popped into my heade:
What about a temporary file and file notifications? (StartNotify)
Can StartNotify() be used on a pipe?
_________________ BroadBlues On Blues BroadBlues On Amiga Walker Broad |
| | Status: Offline |
| | Wanderer
|  |
Re: Reading STDOUT from another Tool Posted on 18-Mar-2013 17:00:39
| | [ #14 ] |
| |
 |
Cult Member  |
Joined: 16-Aug-2008 Posts: 654
From: Germany | | |
|
| @broadblues
I also thought about a temporary file in RAM Disk or T:, since you can read without the fear to get blocked for long. But there is a similar problem with getting notified when new data is pending. Start/EndNotify will send you a notifcation only when the file is closed by the writing process, at least I read it like this from the documentation. Means, I would need a busy polling too, which I would like to avoid. But might get me rid of the seperate process, though. Last edited by Wanderer on 18-Mar-2013 at 05:01 PM.
_________________ -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more... Homepage: http://www.hd-rec.de |
| | Status: Offline |
| | Wanderer
|  |
Re: Reading STDOUT from another Tool Posted on 19-May-2013 16:22:05
| | [ #15 ] |
| |
 |
Cult Member  |
Joined: 16-Aug-2008 Posts: 654
From: Germany | | |
|
| @Wanderer
Its me again. Things work fine now, in general.
If I try GCC however, I dont get any output. I was wondering why. Does GCC write to STDERR and I dont catch this?
I call SytemTagList() with "SYS_Output, myPipeFH". I checked the docs and there is no such things as SYS_ErrOutput or something.
I am pretty sure GCC does some output, since when I call it from shell I get a lot of stuff. I do
GG:bin/gcc Work:Sourcecodes/_C/dumb/dumblib_init.c -c -Q
_________________ -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more... Homepage: http://www.hd-rec.de |
| | Status: Offline |
| | Wanderer
|  |
Re: Reading STDOUT from another Tool Posted on 20-May-2013 17:10:31
| | [ #16 ] |
| |
 |
Cult Member  |
Joined: 16-Aug-2008 Posts: 654
From: Germany | | |
|
| GCC is writing most of the stuff to errout. How can I redirect errout with SystemTagList()?
EDIT: I found there is "SYS_ErrorOutput" Tag on OS4.x. However, there is no such thing on OS3.x. Is there still a way to catch GCCs error outout? Last edited by Wanderer on 20-May-2013 at 05:18 PM.
_________________ -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more... Homepage: http://www.hd-rec.de |
| | Status: Offline |
| | Hypex
 |  |
Re: Reading STDOUT from another Tool Posted on 21-May-2013 14:12:33
| | [ #17 ] |
| |
 |
Elite Member  |
Joined: 6-May-2007 Posts: 11351
From: Greensborough, Australia | | |
|
| @Wanderer
Does the 68K GCC still have some sort of errout that doesn't get sent to stdout? The error output concept exists in OS4 but I'm not aware of it existng in OS3. Last edited by Hypex on 21-May-2013 at 02:49 PM.
|
| | Status: Offline |
| | broadblues
 |  |
Re: Reading STDOUT from another Tool Posted on 21-May-2013 14:37:27
| | [ #18 ] |
| |
 |
Amiga Developer Team  |
Joined: 20-Jul-2004 Posts: 4456
From: Portsmouth England | | |
|
| | | Status: Offline |
| | Wanderer
|  |
Re: Reading STDOUT from another Tool Posted on 21-May-2013 14:52:03
| | [ #19 ] |
| |
 |
Cult Member  |
Joined: 16-Aug-2008 Posts: 654
From: Germany | | |
|
| @broadblues
I dont even know how to write GCC output in a file.
gcc >log.txt test.c
writes everything on the console, and creates an empty log.txt file.
&>, *>, 1>, 2> doest work under OS3. Last edited by Wanderer on 21-May-2013 at 02:52 PM.
_________________ -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more... Homepage: http://www.hd-rec.de |
| | Status: Offline |
| | broadblues
 |  |
Re: Reading STDOUT from another Tool Posted on 21-May-2013 16:30:31
| | [ #20 ] |
| |
 |
Amiga Developer Team  |
Joined: 20-Jul-2004 Posts: 4456
From: Portsmouth England | | |
|
| @Wanderer
Quote:
I dont even know how to write GCC output in a file.
gcc >log.txt test.c
writes everything on the console, and creates an empty log.txt file.
|
That's because most of what gcc writes is errors and warnigs to stderr.
gcc --version >ram:versioninfo
will work as you would expect as the version info is going to stdout (I think, not testing directly on OS 3 here, so relying on memory).
This is why I suggest wrapping gcc in a sh call and redirecting ixemul stderr stream that way ( 2>&1 redirects stderr to stdout, and I'm hoping that ixemiul stdout is the same as the OS)
Quote:
&>, *>, 1>, 2> doest work under OS3.
|
No not under AmigaDOS they don't you are correct, of those only *> works for AmigaOS 4.
_________________ BroadBlues On Blues BroadBlues On Amiga Walker Broad |
| | Status: Offline |
| |
|
|
|
[ home ][ about us ][ privacy ]
[ forums ][ classifieds ]
[ links ][ news archive ]
[ link to us ][ user account ]
|