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

[Thorsten Otto <halgara@yahoo.de>]

> Where is that documented?

Its only logical. If that flag is set, $ARGV contains the parameters, not the cmdline.

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

That can be argued about for wiscr == 1. It could mean that XaAES should behave as it does currently. But if the parameter length is 127, it means that the caller has already put the parameters in $ARGV, and that can only be in environment passed with SW_ENVIRON flag set, since the callees enviroment is created by AES.

> They are not truncated with the change in launch() I mentioned before.

If the caller of shel_write() puts a 0x7f into the length byte, he indicates that $ARGV contains the parameters, and that the cmdline contains a truncated version of these, if at all.

> When I add this
>
>    argv[argc++] = "/usr/gem/tw-call.app";
>   argv[argc++] = "callee.tos";
>
> to your example it works.

Yes, but prepending "/usr/gem/tw-call.app" is what shel_write() already does when you execute a *.tos program. It can't be the task of the application to do that, and would only work on XaAES.

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

What i meant is that wisgr is set to 1 in that case, and that the codepath for TOS programs is not used.

Helmut Karlowski <helmut.karlowski@ish.de> schrieb am 2:22 Sonntag, 7.Februar 2016:

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