Click Here
home features news forums classifieds faqs links search
6155 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
» Home
» Features
» News
» Forums
» Classifieds
» Links
» Downloads
Extras
» OS4 Zone
» IRC Network
» AmigaWorld Radio
» Newsfeed
» Top Members
» Amiga Dealers
Information
» About Us
» FAQs
» Advertise
» Polls
» Terms of Service
» Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
22 crawler(s) on-line.
 95 guest(s) on-line.
 0 member(s) on-line.



You are an anonymous user.
Register Now!

/  Forum Index
   /  Amiga Development
      /  Reading STDOUT from another Tool
Register To Post

Goto page ( 1 | 2 Next Page )
PosterThread
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
Profile     Report this post  
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
Profile     Report this post  
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
Profile     Report this post  
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
Profile     Report this post  
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
Profile     Report this post  
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
Profile     Report this post  
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
Profile     Report this post  
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
Profile     Report this post  
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
Profile     Report this post  
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
Profile     Report this post  
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
Profile     Report this post  
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
Profile     Report this post  
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
Profile     Report this post  
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
Profile     Report this post  
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
Profile     Report this post  
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
Profile     Report this post  
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
Profile     Report this post  
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

@Hypex

68k gcc toolchain uses ixemul.library so might have a real and distinct stderr.

perhaps try executing via a ksh and redirect stderr to sdtout

'sh -c "gcc 2>&1"'

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

 Status: Offline
Profile     Report this post  
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
Profile     Report this post  
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
Profile     Report this post  
Goto page ( 1 | 2 Next Page )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle