[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hi,

On 02/07/2016 03:22 AM, Helmut Karlowski wrote:
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?

For example:
	http://toshyp.atari.org/en/005011.html


	- Eero

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