Re: [MiNT] XaAES: bug(s) in shel_write()

["Helmut Karlowski" <helmut.karlowski@ish.de>]

Am 06.02.2016, 15:47 Uhr, schrieb Thorsten Otto:

> It doesn't, and that is part of the problem. But it looks at the length  
> byte being 127 (or wiscr being 1). If the length byte is 127, the  
> parameters should *only* be taken from the ARGV environment variable.

Where is that documented?

> The contents of the cmdline are irrelevant in this case, maybe they  
> contain the first 126 chars of the parameters, but even that cannot be  
> guaranteed, and they are definitely truncated.

They are not truncated with the change in launch() I mentioned before. I  
can pass deliberately many bytes to the callee. The drawback is that the  
arguments may not contain white-space.

> BTW: the comment in mt_gem.h reads:#define CL_PARSE             1        
> /**< command line passed in ARGV environment string, see mt_shel_write()  
> */

But it does not mention who's environment (caller's or callee's).

> > strings is written in make_argv().
> You are right, i misunderstood that code. Looks like strings and C.env  
> are identical in that case. But it still would fail if the caller passes  
> its own enviroment via SW_ENVIRON, and shel_write() builds a new  
> environment (maybe only because constructing the new command line  
> exceeds the limit).

It fails because the first entry in ARGV must be tw-call. When I add this

    argv[argc++] = "/usr/gem/tw-call.app";
    argv[argc++] = "callee.tos";

to your example it works. That might be a bug in XaAES. It should  
re-create ARGV with the addition of argv[0]=tw-call.app (or whatever) and  
shift the remaining part. Pretty sure no-one ever used SW_ENVIRON, yet I  
don't know if it's safe to change anything in XaAES on that matter. In any  
case it would be easier for XaAES if the caller would start with argv[1]  
and leave argv[0] empty when it expects tw-call to do the job.

> > I have attached my test-programs. Is it this what you mean?
> Basically, yes. One major difference though is that your sample code  
> uses mode 0, and since your callee does not have a ".tos" extension, it  
> will be run as GEM application, not using $TOSRUN.

It prints the output to stdout of the shell I started caller.prg from, no  
new window.

-Helmut